Replication : Encryption and WAN accelerator optimizer

[homerjnick]

Quick question, I did search on the forums but couldn't see the answer.

Is replication encrypted? We are testing a WAN Optimiser which I was advised works well with Veeam replication traffic.

But the traffic cannot be encrypted. Running tests last night we see no benefit from the WAN Optimiser and the 3rd party are asking if the replication traffic is encrypted.

[Vitaliy S.]

Hi Nick,

No, encryption is not used when you perform replication jobs.

Thanks!

[homerjnick]

Thanks...thought as much!

[tsightler]

To get significant benefit from a WAN accelerator you will likely need to disable compression on the Veeam job to allow the WAN accelerators compression and dedupe to be effective. If your WAN accelerator does not support caching (i.e. is just a WAN optimizer) then you probably won't see a lot of benefit, however, there can be significant benefit from caching WAN accelerators assuming Veeam compression is disabled, especially for incremental runs.

[homerjnick]

Indeed, it was compression that was the issue...I took this off and got a 30% reduction in traffic...I am testing further tweaks as the third party say you can get much better than that with Veeam replication traffic and their WAN Optimiser.

[Gostev]

30% comparing to what? Comparing to what Veeam w/compression uses? How did you compare - full replication in both cases?

Also, who is the vendor? Their statement is likely related to the previous B&R version (v5), because we found that v6 no longer benefits from WAN optimizers. WAN accelerators is different story though, there I would expect you to see noticeable benefit still.

I am just naturally interested in your findings, as I plan to touch this subject on my VMworld session.

[tsightler]

Anton is 100% right on this. The land of WAN optimization/acceleration is full of claims and counter-claims, and various vendors use different terminology, but I would say that products generally fall into one of two very broad categories "Caching WAN Optimizer" or "Transport Layer WAN Optimizer". My work with clients has shown that caching WAN optimizers can still provide significant bandwidth savings with Veeam replication even with V6, however, compression must be disabled on the job. Of course, the big disadvantage is that any space used for caching of the replication data is not available for caching of client data, so you have to strike a balance and decide your own priorities.

On the other hand, WAN optimizers that work only and the transport layer, i.e. improving the efficiency and reliability of TCP, are unlikely to offer significant bandwidth savings compared to simply using Veeam compression/dedupe. That's not to say that these tools can't sometimes be useful. For example, some links can experience small "drops", for example during IPsec rekey operations on a VPN tunnel, or long distance wireless or satellite links, or even simply unreliable internet links. In these situations a long replication cycle is likely to crash, but these transport layer optimizers can many times "hide" these short outages from the TCP layer by faking TCP retransmits/keepalives and filtering ICMP unreachable messages from reaching the proxies. This can allow long running replication jobs to finish more consistently in the presence of the less than reliable WAN links.

[J1mbo]

When I looked at the WAN optimising products recently, it seemed that their pricing structures were somewhat aspirational - WAN optimiser + 10Mbps circuit was generally significantly more than a 100Mbps circuit. I guess it depends on location.

[tsightler]

WAN optimizers also address a different problems than just bandwidth. For example most solutions that include caching implement protocol helpers that are designed to help with latency issues as well. Having a network background I can't tell you the number of times that I was called onsite to tell a customer "why the WAN was so slow". They would make statements like "we have 10Mbps, or 100Mbps, it should be fast", but then I'd look at the latency only to see that it's 50ms and have to explain how that impact the SMB protocol (or the protocol of whatever application they were using). WAN accelerators can address this issue quite nicely. This can be especially true for long links such as to Europe or Asia, where the latency is likely to be measured in the 100's of ms.

And exactly as you say location is a huge factor as well when it comes to cost of a line. In some cases I was able to get 1Gbps connectivity for not much more than 10Mb, in others, a couple of bonded T1's was all you could hope for, then the price of more bandwidth was prohibitive. WAN optimizers were easy to justify in that situation.