VMware recently introduced vSphere version 6.0. One of the features of vSphere 6.0 is vSphere Replication 6.0, which is included in the Essentials Plus Kit and higher editions of vSphere. The reason I mention that explicitly is there are still many VMware customers and partners that do not realize they have access to a mature, proven host-based replication technology for their vSphere virtual machines. vSphere Replication is also compatible with VMware Virtual SAN and vCenter Site Recovery Manager.
Enabling compression is very easy – it is simply a checkbox that can be checked when configuring replication in the vSphere Web Client.
vSphere Replication 6.0 utilizes the FastLZ compression library. This provides a nice balance of speed, minimal CPU overhead, and compression efficiency. When using vSphere 6.0 and vSphere Replication 6.0 at both the source and target locations, updates are compressed at the source and stay compressed until they are written to storage at the target. In cases where there is a mixed configuration, packets may be decompressed at some point in the replication path. For example, if a vSphere 6.0 host is connecting to a vSphere Replication 5.8 virtual appliance, packets will not be compressed over the network. Another example: vSphere 6.0 replicating to a vSphere Replication 6.0 virtual appliance, which is writing to vSphere 5.5 host storage – packets are compressed from the source to the vSphere Replication 6.0 virtual appliance, but are decompressed in the appliance before being written to the vSphere 5.5 storage at the target. Performing this decompression in the vSphere Replication virtual appliance will cause higher vCPU utilization in the appliance. As you can imagine, the most benefit from compression will be realized when running vSphere 6.0 and vSphere Replication 6.0 at both the source and target locations.
For most replication workloads, you will likely see compression ratios of approximately 1.6:1 to 1.8:1. This will result in faster sync times and lower bandwidth utilization. Here are a few examples:
A Windows VM with 37.5GB of data took 52 minutes for the initial full sync when compression was not enabled (the default setting). When compression was enabled, 20.2GB of data was replicated in 29 minutes. Compression raised the effective throughput from 98 Mbps to 177 Mbps.
A Linux VM with 4.7GB of data took 13 minutes for the initial full sync when compression was not enabled. With compression enabled, 2.8GB of data was replicated in 8 minutes. Effective throughput went from 49 Mbps to 80 Mbps.
As with any compression, there is a price to pay in the form of CPU cycles. Fortunately, most environments have spare CPU capacity on their hosts, which means enabling compression for replicated VMs should have very little if any impact. However, it is recommended you enable compression for a few VMs at time and only where necessary until you have a good understanding of the impact this will have to your production hosts – especially if you replicate larger numbers of virtual machines.
