The features on this slide are new in vSphere Replication (VR) 6.0
- Compression can be enabled when configuring replication for a VM. It is disabled by default.
- Updates are compressed at source (vSphere host) and stay compressed until written to storage. This does cost some CPU cycles on source host (compress) and target storage host (decompress).
- Uses FastLZ compression libraries. Fast LZ provides a nice balance between performance, compression, and limited overhead (CPU).
- Typical compression ratio is 1.7 to 1
Best results when using vSphere 6.0 at source and target along with vSphere Replication (VR) 6.0 appliance(s). Other configurations supported – example: Source is vSphere 6.0, target is vSphere 5.5. vSphere Replication Server (VRS) must decompress packets internally (costing VR appliance CPU cycles) before writing to storage.
- With VR 6.0, VR traffic can be isolated from other vSphere host traffic.
- At source, a NIC can be specified for VR traffic. NIOC can be used to control replication bandwidth utilization.
- At target, VR appliances can have multiple vmnics with separate IP addresses to separate incoming replication traffic, management traffic, and NFC traffic to target host(s).
- At target, NIC can be specified for incoming NFC traffic that will be written to storage.
- The user must, of course, set up the appropriate network configuration (vSwitches, VLANs, etc.) to separate traffic into isolated, controllable flows.
VMware Tools in vSphere 2015 includes a “freeze/thaw” mechanism for quiescing certain Linux distributions at the file system level for improved recovery reliability. See vSphere documentation for specifics on supported Linux distributions