vSphere Replication 6.0 Compression Method

By | 23/10/2017

With vSphere Replication 6.0, VMware added a new feature named “Network Compression” and you have noticed this while configuring replication for a virtual machine. 

data compression-0.PNG

What is Network Compression?

It is a method for compressing the replication data that is transferred through the network which helps in saving network bandwidth and might help reduce the amount of buffer memory used on the vSphere Replication server. However, compressing and decompressing data requires more CPU resources on both the source site and the server that manages the target datastore.

Do you really need network compression in your infrastructure?

vSphere Replication uses CBT technique to replicate changed blocks to a DR site (which commonly exists in cloud these days) and the DR site is usually connected to primary site via a WAN link. These WAN links typically have limited bandwidth or high latency. Network compression can save your precious WAN bandwidth.

VR data compression support

vSphere Replication 6.0 supports end-to-end compression when the source and target ESXi hosts are also version 6.0. Also the VR appliance on both source and target sites must be running v6.0 or greater.

The support of data compression for all other use cases depends on the versions of source and target ESXi hosts. Below table explains when you can use compression and when not.

data compression.PNG

Compression method used by vSphere Replication

vSphere Replication 6.0 utilizes the FastLZ compression library, which is very light weight compression method optimized for balancing speed with minimal CPU overhead, and compression efficiency. 

Important: Although network compression is enabled via VR configure replication wizard, data compression/decompression is actually done by Esxi hosts. Esxi host at primary site can intercept I/O write requests that originate from VM configured to be replicated via HBR, the I/O write requests being destined for a virtual disk (VMDK) of the VM.

Esxi host then further track VMDK file blocks that are modified by the I/O write requests and can retrieve the VMDK file blocks from a storage tier at the primary site. The hypervisor can then compress the retrieved VMDK file blocks and transmit the compressed blocks to a secondary site.

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 vSphere 6.0 replicating to a VR 6.0 virtual appliance, which is writing to vSphere 5.5 host storage – packets are compressed from the source to the VR 6.0 virtual appliance, but are decompressed in the appliance before being written to the vSphere 5.5 storage at the target. 

I hope you find this post informational. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

Category: vSphere Replication

About Alex Hunt

Hi All I am Manish Jha. I am currently working in OVH US as Operations Support Engineer (vCloud Air Operations). I have around 7 Years of IT experience and have exposure on VMware vSphere, vCloud Director,vSphere Replication, vRealize Automation, NSX and RHEL. If you find any post informational to you please press like and share it across social media and leave your comments if you want to discuss further on any post. Disclaimer: All the information on this website is published in good faith and for general information purpose only. I don’t make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on this blog is strictly at your own risk. The Views and opinions published on this blog are my own and not the opinions of my employer or any of the vendors of the product discussed.