Replicate VMs

Replicate VMs

Understanding replication of VMs

vRanger includes integrated replication based on the proven technology of vReplicator, enabling replication of VMware® virtual machines (VMs) both on site and at remote locations for flexible and efficient disaster recovery preparedness. Combine backup and replication jobs to ensure that you meet your organization’s recovery time and recovery point objectives. Perform fast VM failover and recovery at all your sites, no matter where they are located.

 

NOTE: Replication is not available for Hyper-V® VMs. If you are looking for information on replicating Quest RDA and EMC DD Boost repositories, see Managing repository replication.

A VM is made up of a set of files. Replicating a VM is, in essence, replicating the set of files that make up the VM, with changes to these files that reflect user-specified settings for the source VM.

Be aware of the following regarding the destination that you target for a replication:

•

You can change the storage-destination settings. Although vRanger uses the defaults from the original configuration, you change the host and storage targets. For example, you can replicate from a non-VVol datastore to a VVol datastore. In another example, you can replicate from a datastore that is governed by one storage policy to a datastore that is governed by a different policy, or no policy.

•	You can select different storage for the target of the primary VM file versus the disks.

•	If the target uses DRS, you must select the DRS, which governs which datastore in the cluster is used at replication time; you cannot select a specific datastore.

•	If your environment uses storage policies, datastores are listed under the applicable policy. Any datastores not associated with a storage policy are listed separately.

The following table lists the set of files replicated by vReplicator:

 

Table 1. Files replicated

File extension	Description
.vmx	The VM config file, one per VM.
.vmxf	The extended VM config file, one per VM.
.nvram	The VM BIO file, one per VM.
.vmdk	The VM hard disk file, one per hard disk or snapshot.
-flat.vmdk	The VM hard disk data file, one per hard disk or snapshot.
-delta.vmdk	The VM snapshot data file, one per snapshot.
-ctk.vmdk	The VM hard disk change tracking file when CB is enabled on the disk.

How replication works

Replicate VMs

Understanding replication of VMs

vRanger includes integrated replication based on the proven technology of vReplicator, enabling replication of VMware® virtual machines (VMs) both on site and at remote locations for flexible and efficient disaster recovery preparedness. Combine backup and replication jobs to ensure that you meet your organization’s recovery time and recovery point objectives. Perform fast VM failover and recovery at all your sites, no matter where they are located.

 

NOTE: Replication is not available for Hyper-V® VMs. If you are looking for information on replicating Quest RDA and EMC DD Boost repositories, see Managing repository replication.

A VM is made up of a set of files. Replicating a VM is, in essence, replicating the set of files that make up the VM, with changes to these files that reflect user-specified settings for the source VM.

Be aware of the following regarding the destination that you target for a replication:

•

You can change the storage-destination settings. Although vRanger uses the defaults from the original configuration, you change the host and storage targets. For example, you can replicate from a non-VVol datastore to a VVol datastore. In another example, you can replicate from a datastore that is governed by one storage policy to a datastore that is governed by a different policy, or no policy.

•	You can select different storage for the target of the primary VM file versus the disks.

•	If the target uses DRS, you must select the DRS, which governs which datastore in the cluster is used at replication time; you cannot select a specific datastore.

•	If your environment uses storage policies, datastores are listed under the applicable policy. Any datastores not associated with a storage policy are listed separately.

The following table lists the set of files replicated by vReplicator:

 

Table 1. Files replicated

File extension	Description
.vmx	The VM config file, one per VM.
.vmxf	The extended VM config file, one per VM.
.nvram	The VM BIO file, one per VM.
.vmdk	The VM hard disk file, one per hard disk or snapshot.
-flat.vmdk	The VM hard disk data file, one per hard disk or snapshot.
-delta.vmdk	The VM snapshot data file, one per snapshot.
-ctk.vmdk	The VM hard disk change tracking file when CB is enabled on the disk.

How replication works

How replication works

During the replication process, the configuration files are created and modified on the target server by way of the VMware® API.

A set of working files is also created and used during the replication process. The following table lists these files and their purposes:

 

Table 2. Working files

File extension	Description
.vzmap	Records data block offset and hash of files on the target VM. A .vzmap file is created for each of the files replicated at the end of the replication. The .vzmap file is used by the next replication pass to detect any data changes since the previous pass. It stays on the target VM as long as the job is still configured to run. While relatively small, the size of the .vzmap file is directly proportional to the size of the VMDK it is based on. During replication, the .vzmap file is stored on the target VA.
vzundo-script	A script created by the replication process to roll back changes on the target VM if there is a replication failure. This file created on the target VA at the start of the replication process and removed at the end.
.vzundo	This file is a temporary file that records original data of changed blocks since the replication started. One for each VMDK replicated. If there is a replication failure such as a network failure, the vzundo-script can be run to restore files to their original state. These files are created on the VA by the replication process and removed when the job is completed. NOTE: The .vzundo file is as large as the amount of changed data replicated during a given pass. For example, if a replication pass sends 20 GB of changed data to the target VA, the .vzundo file is 20 GB.
.vmdk-abbt.vztemp	Active block filter file. One for each hard disk data file when ABT is enabled. It records active data block offsets for source VM disks. This file is used against the .vzmap file to figure out data blocks that need to be streamed to the target. It is created at the start of the replication process and removed when disk replication is completed.
.vmdk-abfg.vztemp	Change block filter file. One for each hard disk when Changed Block Tracking (CBT) is enabled. It records changed block offsets for source VM disks. This file is only generated when CBT and ABT are both enabled. It is later combined with the .vmdk-abbt.vztemp file into -flat-map.vztemp and removed.
-flat-map.vztemp	Disk data filter file. One for each hard disk when one of two situations are true: CB is enabled, or both AB and CB are enabled. It contains active and changed data block offsets that need to be compared to the .vzmap file at the target to figure out data blocks that need to be streamed to the target. It is created right before file replication starts and removed when file replication is completed.
.vzcid	Records target VM disk CIDs at the end of the replication pass.

Replication with the virtual appliance (VA)

Replication with the virtual appliance (VA)

vRanger supports VMware® ESXi™ replication by way of the vRanger VA, which leverages the VMware® HotAdd disk transport mechanism. After the VAs are configured and deployed, the use of the VA is automatic and transparent. The following lists some key points about replicating with the VA:

•	For instructions on deploying and configuring the VAs, see the Quest vRanger Installation/Upgrade Guide.

•	At a minimum, deploy one VA on every ESXi server that you plan to use as a replication source or target. For hosts in a cluster, you can deploy the VA to only one host in the cluster; the VA is shared among the cluster’s other hosts.

VAs must be used in pairs. For example, if you are replicating to a target host or cluster that is using a VA, use a VA on the source host or cluster as well.

•	Due to VMware limitations on how snapshots are handled during HotAdd operations, hardware changes to the source VM occurring after a job has been configured are not replicated to the target VM. For more information, see Replication modes.

Communication between the VAs occurs through an SSH tunnel using AES-256 encryption. For more information, see the Encryption description in Major feature list.

Additional replication requirements

The following limitations and requirements apply to replication:

•	vRanger replication does not operate with servers that are behind a network address translation (NAT) firewall. To replicate through a NAT firewall properly, you must have an IP tunnel in place between two NATed subnets. Contact your ISP provider to see if this option is available to you.

•

The VM hardware cannot be changed during replication. For this reason, the VM must be at a hardware version level that is compatible with both the source and target servers. The VMware® ESXi™ version of the source and target hosts does not matter, as long as the VM hardware is supported on both ESXi versions. For more information on VM hardware versions and compatibility, see the VMware documentation at https://www.vmware.com/support/pubs/.

•	A continuous connection between source and target sites is required when replication is taking place.

•	Excessive network packet loss could result in replication failure. Replication does work with links having average packet loss of less than 2%. Replication is not designed to work in replication environments where packet loss exceeds commercially accepted limits.

•	Networks having 99% uptime and availability generally provide for good Replication performance.

Replication with user snapshots

When replicating a VM that contains user snapshots, vRanger replicates all the snapshots in the chain from the current snapshot to the base disk. At the target side — the VM to which changes are replicated — the snapshots are merged into a single disk.

Snapshots not in the chain of the current snapshot are not replicated. In the following image, ss2 is the current snapshot. Only ss1 and ss2 are replicated. Snapshot 3 (ss3) is a lateral snapshot to ss2, while ss4 is a child to ss2.

 

NOTE: Replication with user snapshots applies only to replication using the VA.

Capturing hardware changes with replication

It is not possible to replicate hardware changes that occur on the source VM after the job has been configured. This issue is due to a limitation in how snapshots are processed by HotAdd.

If you make hardware changes on the source VM, you need to configure the target VM in the same way before the next replication pass. You might also need to edit the replication job to include the new hardware.

Active Block Mapping (ABM)

ABM filters deleted data blocks so that only active blocks are scanned and streamed to the target. White-space detection eliminates the need to compress, stream, and write zero blocks during the replication process. vRanger offers the following ABM settings options:

•	Do not include the Windows page file.

•	Do not include the Windows hibernation file.