Replication Receiver Clouds: Protecting your Data

Security in the cloud and the virtual environment is ‘all about the data’ and not specifically about any other subsystem. It is about the data. As such the data has something it knows (the contents of the data), something it is (its signature), and something it has (its digital rights) and since it has these three elements, the data has all it has identity. However, protecting the data requires us to put things between the data and the real world such as firewalls, and complex role based access controls, as well as methods to replicate the data to other locations in a non-intrusive mechanism.  The goal to such replication could be to ensure multiple sites have the same data (such as a hot-site) or to have the data available in another locations in case of disaster. In addition, such data must maintain its identity.
Regardless of the reasons, data replication is a major component of any disaster avoidance, disaster recovery, or backup strategy and as such we need to ensure the replicated data not only maintains its identity but also replicates continuously.In Virtualized Replication: vSphere APIs Expand I briefly outlined a new way to do replication used by SRM and ZeRTO. The mechanism differs from the current replication tools in two ways: it is not snapshot based, and is not from within the Guest OS.  There are several advantages to this new method with the first being there is no need to depend on the operating system in use, and second there is no need to use up even more storage space to hold a local snapshot while the replication takes place.
However, nearly all replication while perhaps not dependent on the operating system in use, is dependent upon the application using the data as not all applications store data to the disk on write. To get better performance many bits of data is cached in memory and that would leave holes in any replication scheme. To this end, before all replication can be performed the data must be written to disk. As such all replication regardless of where it takes place must be able to integrate with an operating system. For VMware products, this is performed by running scripts that are part of VMware Tools to do such disk synchronizations, or by creating new scripts that are specific to a guest operating system functionality such as working with Microsoft’s VSS. This must happen to preserve the identity of the data to be replicated.
The ultimate goal of any replication method is to have the data replicated to a ‘name-your-tool’ replication receiver cloud offering so that all data could be stored offsite with some level of confidentiality and integrity; maintaining the data’s identity.
Enough background, let’s talk about the products currently available or at least the ones communicated to use at Tech Field Day 6 in Boston plus some of the common tools.
VMware SRM Replication
VMware’s latest SRM product will perform Replication (as we saw at Tech Field Day) for any running VM using the mechanism that ties into the vSCSI filters. As such, it is in effect an out-of-band replication method to another location either local or remote. There is not yet a SRM replication receiver cloud solution so this can only take place within a hybrid cloud with SRM in use on both sides. This only works for currently running virtual machines and is a VMware vSphere specific solution. This solution allows for ready-to-start replica’s with the need to setup SRM replication back to the source when a replica is booted.
ZeRTO
Similar to SRM, the tie in for replication takes place using the vSCSI filters and while currently VMware specific there is possibilities for ZeRTO to be used with other hypervisors. ZeRTO takes advantage of its own disk block maps to determine if a block of data needs to be replicated as well as source side deduplication in order to transfer the least amount of data over the wire as possible. ZeRTO has impressive replications speeds using this technology. There is a good chance for ZeRTO based replication receiver cloud offerings. Currently this is a VMware vSphere specific solution and can only replicate running virtual machines. This does not produce a ready-to-start replica, but instead provides a mechanims to extract a ready-to-start replica in any location ZeRTO is configured.
Veeam Backup and Replication
Unlike SRM and ZeRTO Veeam Backup and Replication uses the vStorage API to do its replication. A such it creates a snapshot of a virtual machine then applies its own VSS scripts, and finally copies the data from one Veeam Backup and Replication appliance to another Veeam Backup and Replication appliance. By using the vStorage mechanisms Veeam Backup and Replication can also replicate offline VMs from the source to the target. Veeam Backup and Replication also uses source side deduplication and makes great use of active block tracking (looking for zero’ed or unused blocks) as well as change block tracking (those blocks that have changed) to determine what needs to be sent over the wire. As of this writing this is a VMware vSphere specific solution but will have a Hyper-V version available shortly. This solution has a hot-failover to a ready to start replica. You would need to setup replication back to the other side.
Quest vReplicator (Update)
Quest vReplicator works using the snapshot mechanism and will also work for offline VMs, but does not use the vStorage API, instead it installs as part of the service console and as such is limited to just VMware vSphere ESX and not ESXi products. vReplicator will also create a ready-to-start replica and require the setup replication back to the other side once the the replica is now in use. While vReplicator provides source side deduplication, use of active block tracking and change block tracking, its failure to work with ESXi (per its own documentation) limits its usage in future vSphere environments. This is a vSphere ESX specific solution.
NeverFail Replicator
Unlike all the others tools like NeverFail Replicator work from within the guest operating system and as such are dependent on the operating system and the virtual machine running to perform its replication. NeverFail Replicator is designed to work with the data of specific programs and as such could transfer even less over the wire than any of the other solutions as it is looking just at the data to be replicated and not entire virtual disks. This is a hypervisor agnostic solution that includes the ability to synchronize data back from a running replica.
EMC VPLEX
EMC VPLEX is a hardware solution that allows one to synchronously across 100km (60 miles) or asynchronously over larger distances. As such it plugs in to your storage sub-system just before your data actually hits the disks so that the data can be replicated. To make use of it, you will need to change your presentation and zoning and is not just plug and play. Nor does VPLEX directly support synchronization of data within the VM as it works at the storage layer.  Such synchonization would only be used when virtual machines are teleported using vTeleport from one side to the other side using VMware vMotion. However, to do this successfully there must be a stretch layer-2 network in place. In addition, data synchronization is by-directional but only for block storage and for those blocks written to disk.

Replication Feature Table

Vendor	Offline VMs	Hypervisor Support	Receiver Cloud	Implementation Model	OS Independent	Data Retrieval
VMware SRM		vSphere		vSCSI Filter		Ready-to-Start Replica
ZeRTO		vSphere		vSCSI Filter		Extractable Replica
Veeam Backup and Replication		vSphere Hyper-V (soon)		Snapshot		Ready-to-Start Replica
NeverFail Replicator				OS-Specific		Sync Back from Replica
EMC VPLEX				Hardware		Hardware Sync from both sides
Quest vReplicator1		vSphere ESX Only		Snapshot		Ready-to-Start Replica

Summary
Choosing a replication method depends largely on the amount of data you have and your other data replication requirements. So some basic questions:

• Is this for a hot-site?
• Is this for data-storage?
• Is data stored in-cache before being written to disk (application specifics)?
• How big is my data initially and as we grow?
• Will the replication mechanism support my future hypervisors? ¹

These are the minimal questions I would ask, but ideally you need a solution that is not only fast, but handles your data replication requirements for all data that requires such protection.
An interesting concept is to rent a replication receiver cloud tool for the necessary time it takes to replicate, store, and restore the data. If I know that hurricane is coming my way, renting a tool to replicate my data inland would be a very powerful motivator for protecting the data. Such motivation should spur development of more replication receiver clouds and new methods to sell such replication services.
¹ Update added 6/30/2011