How To With VMware

How To Protect Your VMs with vSphere Replication

vSphere Replication is all too easy, as long as you take it one step at a time.

A fundamental part of protecting IT is ensuring that the services provided by virtual machines are resilient and robust at all levels of the compute stack, from hardware through to the application.

vSphere Replication, a feature introduced with vSphere 5.1, augments the recovery capabilities of the vSphere platform by providing a built-in capability to continually replicate a running VM to another location. Replication creates a copy of a VM that can be stored locally within a cluster or at another site, providing a data source for rapidly restoring a VM within minutes.

vSphere Replication augments offerings in the vSphere availability protection matrix. It provides a solution that grants recovery time better than that of restoring from backup, without introducing the complexity of a complete storage array-based replication configuration. vSphere Replication allows configuring replication on a per VM basis, and significantly rounds out the capabilities of protection offered by vSphere.

vSphere Replication copies a VM to another location, within or between clusters, and makes that copy available for restoration through the vCenter Server Web-based user interface. It continues to protect the VM on an ongoing basis, and replicates changes made to the VM over to the copy. This ensures that the VM is protected and available for recovery without requiring restore from backup.

vSphere Replication is provided as a no-charge component of all eligible vSphere licenses ranging from vSphere Essentials Plus through to the Enterprise Plus edition. As with backups through VMware Data Protection, protecting a virtual machine is a critical function of a hypervisor platform for the datacenter.

Unified management of vSphere Replication is provided via the vCenter Server Web client. This provides a common and unified screen for all aspects of virtual datacenter management, including many aspects of protection such as replication, backup and restore.

vSphere replication is managed via the vCenter Server Web client.

Figure 1. vSphere replication is managed via the vCenter Server Web client. (Click image to view larger version.)

Some replication technologies only provide copies of a virtual machine at a remote site without any consideration for the consistency of the application data within the virtual machine. vSphere Replication can be configured to ensure consistent application data along with virtual machine data with one click, when configuring a virtual machine for replication.

Automatic integration with Microsoft's Volume Shadow Copy Service (VSS) ensures applications such as Exchange or SQL Server databases are quiescent and consistent when replica data is being generated. A very quick call to the VM's VSS layer will flush the database writers for an instant to ensure the data that is replicated is static and fully recoverable.

vSphere replication automatically integrates with Microsoft Volume Shadow Copy Service.

Figure 2. vSphere replication automatically integrates with Microsoft Volume Shadow Copy Service. (Click image to view larger version.)

There are no application agents or administration required for this process -- application consistency is inherent to the copies made by vSphere Replication.

vSphere Replication is a deeply integrated component of the vSphere platform. Changed blocks in the VM disks for a running VM at a primary site are sent to a secondary site, where they are applied to the VM disks for the offline (protection) copy of the VM.

vSphere Replication consists of an agent that is an integral part of the vSphere 5 kernel on each host, and a virtual appliance that is deployed from the management interface.

From a conceptual perspective, the agent is responsible for sending changed data from a running VM, and the appliance receives the replication at a remote site and applies it to the offline disk files for the VM. The vSphere Replication Appliance is also responsible for managing replication, which gives the administrator visibility into the status of protection of the VMs as well as the ability to recovery VMs with a few simple clicks.

Configuring replication for up to 500 VMs through the same management interface that is used for all vCenter operations is a process of right-clicking on a VM (or multiple VMs) and selecting the destination for its replica.

Part of this process is to select a "Recovery Point Objective" which will tell vSphere Replication how old the copy of the VM is allowed to get. It will then attempt to replicate data to meet the Recovery Point Objective at all times, ensuring your VM data is never older than the defined policy for each VM configured for replication.

Set the Recovery Point Objective to replicate data at specific intervals you determine.

Figure 3. Set the Recovery Point Objective to replicate data at specific intervals you determine. (Click image to view larger version.)

vSphere Replication will do an initial full synchronization of the source VM and its replica copy; if desired, a seed copy of data can be placed at the destination to reduce the amount of time and bandwidth required for the initial replication.

After baseline synchronization is complete, vSphere Replication switches to transferring only the blocks of data that have changed. The vSphere kernel itself tracks unique writes to the disk files of protected virtual machines, and identifies and replicates only those blocks that have experienced unique writes during the configured recovery point objective. This ensures a minimized amount of data is sent over the network to the target, and allows for aggressive recovery point objectives. Once unique data is sent, it doesn't need to be sent again. Only changes will be replicated, and the blocks sent to the target location's vSphere Replication Appliance.

At the target location, the data is received and checked within the vSphere Replication Appliance: Only fully consistent data is then written to the target cluster's vSphere hosts and thereby to disk. This manner of waiting for a completely consistent block group ensures recoverability of the replica virtual machine at all times, even if data is lost during transit or a crash occurs at any point during the transfer.

From the perspective of the protected VM, this entire process is completely transparent and requires no changes to configuration or ongoing management. The replication is non-intrusive and irrespective of the operating system within the VM.

vSphere Replication is inherently a lightweight replication protocol. By replicating only changed blocks on an ongoing basis, network bandwidth can be saved, and commit times for data are minimized.

Within this framework recovery point objectives for each VM can be defined ranging from 15 minutes to 24 hours. This recovery point objective can be changed on demand without interruption, allowing administrators the ability to fine-tune replication based on dynamic factors such as change rates, bandwidth availability, and so forth.

Since the recovery point objective is unique to each VM, more critical VMs can be given a more aggressive replication target than others. Groups of VMs, however, can be selected en masse to allow for large changes.

Each disk within a VM can be independently configured to be replicated or not replicated, offering further opportunity to save bandwidth and time for recovery. For instance a database server may consist of multiple disks, one of which is dedicated to a temporary scratch location: This disk is not required for replication. Likewise sometimes a swapfile or paging file is redirected to a dedicated disk that can also be excluded from replication to save bandwidth for transient data.

The replicated disks are independent of format, layout and snapshots of the primary copy. A VM disk file that is thick-provisioned on a fiber-channel SAN at the primary location can be thin-provisioned to local disk for recovery, if so desired. vSphere Replication does away with the requirement that replication needs identical storage hardware. Likewise, since the VM replica will be "cold booted" when recovery takes place, server hardware need not be identical if replicating between clusters.

vSphere Replication allows for policy-driven protection of a VM, as the configuration of a VM's replication is attached as a property of the of the VM itself.

Figure 4. vSphere Replication allows for policy-driven protection of a VM, as the configuration of a VM's replication is attached as a property of the of the VM itself. (Click image to view larger version.)

At its base, vSphere Replication allows for policy-driven protection of a VM, as the configuration of a VM's replication is attached as a property of the VM itself, while allowing for VMs to continue operating without any change, overhead, or interruption.

The tracking mechanism that identifies changed blocks of a VM resides above the storage layer, allowing for replication that is fully independent of disk location, disk format, thin- or thick-provisioned disks, and whether or not snapshots are in use by the VM.

Recovery of a virtual machine may be necessitated by for a number of reasons, ranging from testing, impending outages, or even to recover from a disaster. vSphere Replication is designed to allow administrators the ability to manually recover an individual machine with a small number of clicks in the vSphere Web Client.

With vSphere Replication, recovery of a VM can be started easily by one of three methods. After navigating to the replication status in the vSphere Replication area of the vSphere Web Client, the administrator first selects the VM to be recovered. Selecting "Recover" as an action can be done by right-clicking; clicking the recovery icon, or selecting the "Recover" action from the "Actions" drop down.

vSphere Replication allows for policy-driven protection of a VM, as the configuration of a VM's replication is attached as a property of the of the VM itself.

Figure 5. Here's one way to start a replication. (Click image to view larger version.)

The replica will not be able to be powered on and recovered if the original VM is still reachable and it is still powered on. The primary copy of the VM must be unreachable by vCenter Server or powered off in order to continue.

The next step is simply to choose a destination for the VM -- folder to hold it, and a cluster or resource pool in which it will be powered on.

Once these items are selected, recovery will begin. This process creates a powered on copy of the VM connected to the replica disk, but does not connect any of the virtual network cards to any port groups. This can help avoid situations where the same virtual machine may be active on the network in two locations simultaneously, and keeps duplicates from broadcast collision and routing issues.

Recovery is in progress...

Figure 6. Recovery is in progress... (Click image to view larger version.)

Once the VM is fully booted the administrator reviews the recovery and status of the booted replica, and to complete recovery simply attaches the VM to the appropriate networks.

Recovery of a VM is a simple process that can be accomplished with a few clicks in the GUI in a safe and reliable fashion.

vSphere Replication provides you with recoverable copies of your VMs, either within a datacenter or in another datacenter at another location for simple disaster recovery. Integrated with the vSphere platform, this feature is both robust and easy to implement.

For more information and to see videos, white papers and evaluation guides on using vSphere for business continuity, please visit the VMware website.


Subscribe on YouTube