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).

For more information visit GlassHouse.com, visit the GlassHouse blog for expert commentary on key datacentre issues, and follow us on Twitter @GlassHouse_Tech.

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in October 2013

 

COMMENTS powered by Disqus  //  Commenting policy