vRanger 7.8 - User Guide

Replication with Changed Block Tracking (CBT)

Replication with CBT is the recommended method of replication whenever possible.

CBT tracks the disk block changes made by the source VM. When enabled on the source host, CBT records the blocks that have changed since the last replication pass and transfers them to the target host without scanning the VMDK. CBT only identifies these disk-sector changes when VMware® ESXi™ version 5.0 or later is installed on both of the hosts being used for replication.

The following configurations are required for CBT to be available:

•	The VM to which the disks belong must use Hardware Version 7 or later.

•	CBT must be enabled for the VM you want to replicate.

•	VM storage must not be on an independent disk that is not affected by snapshots.

 

NOTE: NFS is supported. RDM is supported in Virtual Compatibility mode, but not in Physical Compatibility mode. VMFS is also supported, regardless of whether it is backed by a SAN, iSCSI, or local disk.

For CBT to identify disk sectors in use with the special change ID, the following configurations are also required:

•	The virtual disk must be on a VMFS volume, backed by a SAN, iSCSI, or local disk.

 

NOTE: Raw device map (RDM) partitions are not considered VMFS volumes.

•	The VM must have zero snapshots when CBT is enabled for a clean start.

 

NOTE: CBT must be enabled for each VM that you want to replicate. VMware vSphere® supports CBT, and most VMs running in this environment can use it.

Differential replication

In differential replication, vRanger compares the data blocks on the source VM to a data map to identify blocks that have changed since the last replication pass. These changed blocks are sent to the target VM and committed to disk, and the data map is updated to reflect the current state of both VMs.

When using differential replication, consider the following:

•

During the first replication pass, the entire VM image needs to be sent to the target VM. During subsequent replication passes, only changed data is sent. To avoid sending the entire VM image over the network, consider pre-seeding the target VM. For more information, see Pre-seeding replication jobs

•

After the first replication pass, the source VM is scanned and the blocks are compared to the most recent data map. This scanning process can take an average of one minute per gigabyte of hard drive space; however, the actual speed depends on the underlying hardware being used. While only the changed data is sent to the target VM, the entire hard drive must be scanned. When configuring differential replication jobs for large VMs, take this scanning time into account. To eliminate the need for scanning, use replication with CBT if at all possible.

Configuring transport failover options

Replication transport actions occur through HotAdd — LAN-free or network. If one transport method is not available, vRanger attempts to perform the replication task using one of the other transport methods. You may configure the order in which vRanger attempts the transport options with the Transport Failover node of the Configuration Options page. For VMware® ESXi™ hosts, configure the transport order to VA-based HotAdd > VA-based Network.

Pre-seeding replication jobs

vRanger replication is intended to replicate changes from a source VM to a remote target. It is often not practical to perform the first replication pass — which sends the full VM) to a remote site over a WAN link. You may use vRanger to “seed” a replication job locally to reduce the amount of data sent over the WAN.

To pre-seed replication jobs, complete the following tasks:

•	Backing up the source VM

•	Replicating the changes

Backing up the source VM

Complete the steps in the following procedure to back up the source VM.

To back up the source VM:

1	If vRanger is not already installed, do so.

2	Select the VM you want to get to the disaster recovery (DR) site, and create a Full backup job.

3	Back up the VM locally.

4	Copy the backup savepoint, and move it to the DR site.

You can complete this step by shipping a USB drive or some other media containing the backup archive.

Savepoints are named using a VMname_date_time_UUID format. Copy the entire directory, which contains a .var file and two .metadata files, for the savepoint in question.

5	Using the Restore from Manifest function documented in Performing a full restore from manifest for VMware VMs, restore the backup to the target VMware® ESXi™ Server at the DR site.

Replicating the changes

Complete the steps in the following procedure to replicate the changes made to the VM.

To replicate the changes:

1	Start vRanger, and expand the host where the source VM is located.

2	Right-click the VM, and select Replicate <VM name>.

3	Configure a replication job with the preferred options.

4	When selecting the target host, select the host on the target side to which the source VM has been restored.

 

NOTE: When selecting the target VM name, ensure that you are using the same name as the source VM. vRanger appends “_VzReplicate” to the VM name on the target side.

5	In the Select Target Host dialog box, next to Preseed VM UUID, click the browse button, and select the pre-seeded VM.

6	When configuring the primary datastore, ensure that it is the same datastore as the restored VM, and click Finish.

7	Run the replication job.

Only the data changes pass over the WAN as opposed to the full VM.