Hyper-V Replica

[ipconfigrenew]

Been experimenting with WANOS and Hyper-V replica. Wanted to know if there is any standard guidance on whether or not to enable compression in the Hyper-V replica settings, or if it's better to disable compression in Hyper-V and let WANOS do all the compression.

[ahenning]

Overall reduction ratios should be better with compression and encryption disabled on the Hyper-V side.

Would be interesting to see your results.

[ipconfigrenew]

Well, my tests so far have been inconclusive.

Obviously the optimization ratio is significantly better when compression is disabled on Hyper-V replication.

WANOS Optimization ratio:
Hyper-V Compression Disabled: 80-90%
Hyper-V Compression Enabled: 5-10%

However, the total WAN utilization (as in the amount data that was seen on WAN connection from beginning to end) seems to be slightly less with compression enabled in Hyper-V.

WAN usage (as reported by pfSense):
Hyper-V Compression Disabled: 25.9GB
Hyper-V Compression Enabled: 23.6GB

So far I've just been doing tests comparing the initial replication task (i.e. the first transfer). I've also been zeroing out the dedup datastore before starting the task to make sure it wasn't effecting the transfer. The transfer is over 40GB raw (it's a Linux Webserver VM that has a mix of compressible and incompressible data) so the datastore is reseeded well before it gets even halfway through the transfer. I'm now going to try and set up a good experiment for daily average usage and see what things look like after some simulated "days".

Also, the "responsiveness" seems better with Hyper-V compress enabled - this is hard to quantify, but the server seems to behave better. My guess is this has to do with the CPU utilization on the WANOS VM being lower when there is less data moving through it.

FYI, my setup:

Hyper-V source server <-> WANOS <-> pfSense <-> Router <-> Router <-> pfSense <-> WANOS <-> Hyper-V destination server

WANOS 2.0.5 (Hyper-V VHD image - 4vCPUs / 4GB memory)
pfSense 2.2.1 (Hyper-V VM - 1vCPU / 512MB memory)
OpenVPN site-to-site L3 routed tunnel (AES-128 / Adaptive compression Enabled)

[ahenning]

Good stats. How does the pfSense wan usage report in GB compare to the Wanos wan0 interface usage? It should be the same, but good to reference with pfsense for a second opinion.

Based on the 25.9GB vs 23.6GB, I think this seems to be a good candidate to enable PLR to help improve the compression ratios further. If Wanos matches or betters the Hyper-V compression (which is end to end), but applies this ratio to all traffic (inline) then its a win.

Also a real world test would be to have the replica traffic start with a full datastore.

The lag I suspect is due to the traffic approaching the express limit. We can load plus keys to confirm.

[ipconfigrenew]

I didn't record the exact stats from WANOS wan0, but did glance at them at the time and they were in the similar (minus the overhead from the VPN, but that's been fairly consistent). I would redo the test, but this has actually been going on for days (did the uncompressed test before I actually posted the original question) and it would take a while to reproduce the exact test again.

I'm setting up a new lab environment to test this further in a more scientific approach. Going to take the VPN and routers out of the equation, and also going to make sure there is no other traffic besides the replica traffic.

As for PLR, my understanding was that it only helps in scenarios where there is packet loss, which as best I can tell there was none (and the WAN in this case was just a 100Mbps network connection between routers so I was in full control of that). Does PLR provide additional compression/dedup benefits? If so, how do I enable it?

I'm already liking this product so it won't be long before I pitch getting plus licenses, but for now I'll just stick with express for the experiments (I can always put a limiter at the Hyper-V level to keep the flow of traffic the same between all tests).

[ahenning]

Yes, when PLR is running it enables additional compression capabilities. Anywhere from 10% additional compression can be expected to 50%.

Its configured by setting the remote wanos ip address. Here are some screenshots and more details here: http://wanos.co/forum/index.php?topic=162.msg729#msg729

At the moment it is also required to configure specific bypass rules for traffic that flows through the one side but not the other (typically a router or firewall in the wan).

[ipconfigrenew]

So I got the PLR status to come up, but as soon as I start a transfer of any kind it drops the PLR status.

Thu Apr  9 06:28:38 2015 : rsp_peer0 - State set to CLOSED
Thu Apr  9 06:28:38 2015 : rsp_peer0 - State set to SYN_SENT
Thu Apr  9 06:28:38 2015 : rsp_peer0 - State set to OPEN
Thu Apr  9 06:28:38 2015 : comp0 WComp Info - Clearing force stateless.
Thu Apr  9 06:29:17 2015 : rsp_peer0 RSP WARNING - Maximum retransmits reached, changing mode to server.
Thu Apr  9 06:29:17 2015 : hard setting force
Thu Apr  9 06:29:17 2015 : rsp_peer0 - State set to LISTEN

[ahenning]

At the moment very specific bypass rules is required for traffic that does not flow through both Wanos devices.

Also, please send me the registration tokens so that we can load trial keys to see if the express limit is the cause.