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.
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.
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 🙂