Thursday, January 26, 2017

vSphere Replication Synchronization Types

vSphere Replication is VMware’s hypervisor-based virtual machine replication solution that is included with vSphere Essentials Plus Kit and higher editions. We commonly get questions around the differences between the various types and modes of synchronization — or “sync” — vSphere Replication utilizes. This article covers sync types and modes and discusses related performance improvements introduced with vSphere Replication 6.0.



We will start with defining the types of synchronization:

Full sync: With vSphere Replication versions 5.x, the entire contents of a source virtual disk (VMDK) and its target virtual disk are compared using checksums. This process identifies the differences between the source and target virtual disks. Comparing the source and target virtual disks requires reading the entire contents of each disk and the generation of checksums. Creating and comparing the checksums of the source and target require CPU cycles. While checksum comparisons are being calculated and compared, vSphere Replication will periodically send any differences that were discovered. The amount of time it takes to complete a full sync primarily depends on the size of the virtual disk(s) that make up a virtual machine, the amount of data that must be replicated, and the network bandwidth available for replication. A full sync occurs in a few scenarios: Most commonly, when replication is first configured for a powered on virtual machine — more on this in a moment — and if there is some sort of exception where vSphere Replication loses track of changes that have occurred at the source, which is far less common. vSphere Replication 6.0 introduced improvements to this process depending on the type of datastore and virtual disk format in use, which will be covered later in this article.

Initial full sync: When replication is first configured for a powered on virtual machine, vSphere Replication performs an initial full sync.


It is really no different from a full sync, as described above. An empty virtual disk is created at the target location. vSphere Replication compares the source and (empty) target disk. Seeing there is no common data between the two, all of the data is replicated from the source to the target. The exception to this would be when replication “seeds” (VMDK clones) are used when configuring replication. This method is discussed in the VMware KB Article: Cloning individual virtual machine disks via the ESX/ESXi host terminal (1027876)

Delta sync: After a full sync has completed, the vSphere Replication agent built into vSphere tracks changes to virtual disks belonging to virtual machines configured for replication. A delta sync replicates these changes on a regular basis depending on the recovery point objective (RPO) configured for a virtual machine. For example, changed data in a virtual machine with an RPO of four hours will be replicated approximately every four hours. This schedule can change based on a number factors such as data change rates, how long each replication cycle takes, and how many virtual machines are configured for replication on the same vSphere host. vSphere Replication uses an algorithm that considers these factors and schedules replication accordingly to help ensure the RPO for each replicated virtual machine is not violated.

Before we get into the sync modes, it is important to understand that automatic, i.e., scheduled, replication only occurs when a replicated virtual machine is powered on. Replication can be configured for a virtual machine that is powered off, but automatic replication will not occur until the virtual machine is powered on. If replication is configured for a powered off virtual machine, a warning is displayed in the vSphere Replication user interface and on the Summary tab for the virtual machine.


It is possible to initiate replication manually for a powered off virtual machine, as shown in the screen shot below.


That takes us to the two sync modes: “online sync” and “offline sync”…

Online sync: Full and delta syncs that occur while a virtual machine is powered on. A scheduled or manually initiated sync while a virtual machine is powered on is considered an online sync. There are no special considerations for an online sync as this is, by far, the most common mode of synchronization.

Offline sync: This mode is used for full syncs and delta syncs that are initiated when the source virtual machine is powered off and vSphere Replication is used to recovery the virtual machine at the target location. The offline sync mode is also used when an administrator initiates a manual sync for a powered off virtual machine. For this operation, the vSphere Replication filter, which is built into vSphere, is attached to the virtual disk(s) to be replicated in a special offline mode. It is important to note that an offline sync locks the virtual disk files (VMDKs), which means the virtual machine cannot be powered on until the offline sync has completed. In other words, the virtual machine might have to remain off for an extended period of time in some cases. One example is a large delta sync over a low-bandwidth connection. Another example is a full sync for a large virtual disk.


You might be asking when an offline sync should occur considering the virtual machine might have to remain powered off for a fair amount of time. The most common use case is when vSphere Replication is used to migrate a virtual machine from one location to another and data loss must be avoided. Here is what the workflow would look like:

  1. Replication is configured for a powered on virtual machine.
  2. vSphere Replication performs an initial sync.
  3. After the initial sync, vSphere Replication automatically performs delta syncs based on the RPO configured.
  4. Since changes do not occur in a powered off virtual machine, the best way to avoid data loss is to gracefully shut down the guest operating system (OS) and then power off the virtual machine (power off after a guest OS shut down occurs automatically in most cases).
  5. Use vSphere Replication to recover the replicated virtual machine at the target location with the “Synchronize recent changes” option selected during the recovery process. Choosing this option when recovering a powered off virtual machine instructs vSphere Replication to perform an offline sync before recovery so that the target is updated with any outstanding changes from the source, i.e., no data loss.

With vSphere Replication 6.0, improvements to the full sync process were introduced. Depending on the datastore type and virtual disk format, vSphere Replication 6.0 and higher versions do not have to perform the checksum comparison for some or even all of the contents of the source and target virtual disks. This can significantly reduce the amount of time, disk I/O, and CPU cycles utilized to perform a full sync. vSphere Replication 6.x uses disk allocation information, where possible, to determine if source and target data must be compared before sending data from the source to the target. For example, if a region of the source disk contains data and it is known that the same region in the target disk is not allocated, vSphere Replication 6.x just sends the data in that region to the target — no need to first compare the contents of the source and target.

As mentioned before, the full sync performance improvements in vSphere Replication 6.x depend on a few factors. vCenter Server and vSphere Replications versions must match, e.g., vSphere Replication 6.5 requires vCenter Server 6.5. vSphere Replication 6.x is supported with several versions of vSphere (ESXi), but vSphere 6.x is required to take advantage of the improved performance. The other items are datastore type and virtual disk format. Generally speaking, a thin or lazy zero thick disk format is required and the disk must reside on a VMFS or vSAN datastore. More details can be found in the vSphere Replication documentation.

Hopefully, this clears up any outstanding questions around replication status types that are displayed in the vSphere Replication user interface.

@jhuntervmware on Twitter

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.