It has been a while since i completed the trial.

Hardware acceleration was 6-8 times base rate compared to OpenVPN which is pretty consistently 3 times.

Since the trial i have been happily running w/ OpenVPN and even an upgrade to W2K8 x64 didn't cause issues.

However, with the steady increase in data being replicated i have scheduled the installation of Juniper WAN accelerator next month.

WANscaler and Riverbed are all good ideas but you can not bet the price of this openvpn solution.

This week i have a few Juniper WAN accelerators arriving for a 1 month trial.

It will be interesting to see how much better the transfer rate is compared to a simple openvpn tunnel.

Hi,

I can't open the link, is there something wrong?

You can get even better results using Citrix WANscaler. I´ve seen effective transfer rates of up to 15 MBit/s over a 2 MBit/s SDSL link when using a WANscaler to optimize AIM traffic.

After moving our DR SDS offsite I was disappointed in the AIM throughput that I was seeing through the WAN so I began investigating ways to improve that throughput.

My investigations lead me to WAN acceleration/optimisation solutions. These devices use several methods to improve throughput and responsiveness, an important component is compression. So it occurred to me that Inline compression could be easily achieved with a point-to-point tunnel.

I do a lot of work with site-to-site VPN?s and often see benefits from enabling compression so I decided to give an OpenVPN tunnel a go and the results are surprising.

Here is the information and I hope others may find it useful.

Proof-of-concept design:
-       dcs01 = primary SDS, AIM source
-       dcsdr01 = DR SDS, AIM destination
-       Existing and working AIM relationship using FTP as the transport method
-       OpenVPN 2.1 rc15. Site: www.openvpn.net
o       Encryption and security disabled.
o       Compression enabled.
o       dcs01 VPN IP: 192.168.199.2
o       dcsdr01 VPN IP: 192.168.199.1

Steps:
1.       Install OpenVPN on AIM source and destination servers. I used OpenVPN 2.1_rc15.
2.       For the purposes of testing the concept I initiated a tunnel from the command line.
a.       On dcs01.
i.       Command: openvpn --cipher none --comp-lzo yes --remote dcsdr01 --ifconfig 192.168.199.2 192.168.199.1 --verb 4 --dev tun
b.       On dcsdr01
i.       Command: openvpn --cipher none --comp-lzo yes --remote dcs01 --ifconfig 192.168.199.1 192.168.199.2 --verb 4 --dev tun
3.       On dcs01 using AIM source manager GUI change the IP Address of the dcsdr01 destination server to 192.168.199.1.
4.       Thats it.

Assuming there are no firewall rules in the way and IIS FTP service on dcsdr01 is not bound to a specific IP or restricting access to a specific IP, AIM data will start moving across the tunnel.

In summary average throughputs were (assuming the perfmon counter is KB/sec):

-       With OpenVPN: 2902
-       Without OpenVPN: 1304

Attached is a Excel of some perfmon data.

Notes:
-       To keep the AIM buffer full I did Initialize Volume on a couple of volumes and performed some zero fill on another (may as well kill two birds with one stone by reclaiming some SAU?s.). That is in addition to general data from all the production volumes.
-       The WAN is not dedicated for this purpose, i.e. other data was on the line during the test however the test was carried out after hours to keep other traffic to a minimum.
-       I am certain the type of data being replicated would be a factoring the compression, in this test the zero fill data would have resulted in excellent compression.
-       In my production environment AIM without the tunnel cannot keep up and by the end-of-business the time latency values from busy volumes have blown out to several hours however with the compression tunnel it is able to keep that as low as a few minutes.

Ben