WAN Acceleration: What options are available?

Date July 24, 2009

I've been considering WAN accelerators ever since the sysadmin next door suggested one a month or two ago. I've known about them for a few years, but I didn't realize their full capacity for improving your users' experience until I heard it from him.

If you're unfamiliar with the concept of WAN acceleration, here's an example of how it could help. Suppose you've got a central office and you've got a branch office. Maybe you've got a leased line from your branch office to the main office, or maybe they're just connected over a VPN. Whichever, they send traffic back and forth between them. Because you're sending uncompressed data, by default, you waste a lot of bandwidth. A 100k Excel spreadsheet could easily zip to 10k with even a low-efficiency compression scheme like gzip. WAN accelerators let you do that, except over your network links. Because you can't just send compressed data and hope something on the other end understands it, you've got to have one at each end of the wire, although you can have one terminate multiple remote endpoints, I believe. This would be useful if you had two branch offices, each connected to one main office.

Anyway, I've done a little bit of a market survey to see what's out there, and the leader appears to be Riverbed, which is what my neighbor is using. In addition, there are many others out there, all of which seem to have similar features.

If you want to hear more about the various options, I found this very recent view of what's out there (except from an investment standpoint, but it should give you some idea): http://seekingalpha.com/article/149152-optimizing-the-wan-optimization-space

Are any of you using them? What do you have, and how well does it work?

14 Responses to “WAN Acceleration: What options are available?”

  1. Tarmo said:

    OpenVPN with comp-lzo configuration option.
    http://openvpn.net/index.php/open-source.html

  2. James said:

    I have Juniper WXC500 models between my primary and disaster recovery data centers. The physical connection is a DS3 that shows around 40mbps between the offices when running uncompressed, but that kicks up to 170mbps when the accelerators are active. I measured that speed using Mini Speedtest (free and installs on your own web server).

    I don't have any experience with any other brands, but I can give a solid thumbs up to Juniper. They also have smaller models available. The smaller ones tend to store their data in flash based storage, the larger ones like mine use hard drive based storage.

    although you can have one terminate multiple remote endpoints, I believe.

    All Juniper models can do this. You designate one appliance as the registration server, and can designate another as a secondary registration server in case the primary goes down. Then all your appliances register, and you can specify the topology you want to use (hub, mesh, or point-to-point).

    For the record, they are built so that failure causes them to function like pass through bridges. Failure of the appliance or failure of power to the appliance does not cause any loss of connectivity.

  3. DM said:

    At $WORK we have Silver Peaks installed in a bunch of offices. We're currently in a middle of a upgrade roll out (going from 3xxx to 5xxx).

    Can't say much more as I'm not on the Networking Team.

  4. Dusty Wilson said:

    I was only going to post here for the OpenVPN compression config, but Tarmo beat me to it. Definitely don't underestimate OpenVPN. I like your blog.

  5. Matt Simmons said:

    @Dusty

    Thanks, I'm glad you like it :-) And thanks for seconding OpenVPN. I'm getting the feeling that it's something I'm definitely going to have to take a look at.

    Thanks!

  6. Dusty Wilson said:

    All of our servers (we sell managed mass hosting, no large load-balanced hosting at this point) are hosted in various colo facilities. Almost all of our servers run OpenVZ (container-style virtual machines (though technically not really virtual machines in the VMware/Xen-way, more like a fancy jail)) for client segregation and lots of other reasons (when a custom kernel/module isn't needed). We use OpenVPN to link each physical server together as well as a link to our office and roaming admin laptops/handhelds. Since it exposes separate virtual network devices (in Linux anyway) for each connection class (technically each connection config, but we use them as classes), it is very easy to filewall specific classes of users/servers. If you want your web design guys to have access to specific things, let them through the firewall for just those things. Same with server-to-server connections. Of course you can use IP filtering as well when that makes sense. We use connection class filtering for the big sweeping stuff and IP-based filtering for the pin-point stuff. It has never failed us and is very easy to manage.

    You have the option of bridging or just standard tunneling. We don't (nor want to) use broadcasts or anything else that requires that we share a broadcast domain, so we just go with the usual tunnel. All of our VMs run with 10.* IPs, each server having its own 10.X.0.0/16 (split into smaller subnets as required for our needs). We're probably a bit too fancy when it comes to some of this, but it makes for some fine hosting. Since we use OpenVZ, we can do live migrations between physical servers, even between facilities. Our reverse proxies (at each colo) handles the move across the VPN until the DNS has updated for that VM. (Tie in some DRBD+GFS for a real good time. We don't use DRBD yet for our servers, but it would handle failover beautifully if we did. We do use it in the office for office-specific and app dev things, though. And when we've got a dev VM ready to go live, we just migrate to a physical server at whichever colo we want. This has turned into a run-on parenthetical, so I'll stop now.)

    And in case it matters, OpenVZ works quite well on Windows and Mac OS X as well. The oldest Windows I've tested it with is 2k. Windows does have a bit of a weirdness when it comes to using a tunnel, though. It has to use 4 IPs for each connected client (in its own /30 for Windows annoyance purposes). Such a waste and quite a bother. At least OpenVPN will handle the IP assignments for you.

    I'm interested in hearing what you think of it when you do finally check it out. If you need a tip or a hand, shoot me an email. I'd be happy to help or point you at some helpful docs if you need it.

  7. Sean said:

    If the budget allowed for it, we would be using Riverbeds between our main offices and our datacenter. They are a great piece of kit that can automatically detect other Riverbeds on the network and configure themselves for operation. They did have some issues working with autocad data (which is a big deal in my industry) but that is being worked on.

  8. William Bilancio said:

    At work we use the Riverbed StealHead appliances. We have the 1020 models in all the offices. We had a few problems in the beginning but the Riverbed support is great and they were able to help me and get the units tuned for my environment.

    Now I know of only one software product that doesn't work well with the units. Autocad has been having some issues.

    I would recommend the units though.

  9. Ernie Oporto said:

    Riverbed Steelhead on each end of a link to our DR site. Does wonders for our DoubleTake replication.

  10. Matt Elmore said:

    Another vote for Juniper WX. It's a great product.

  11. Bob Gilbert said:

    Hi Matt,

    I work for Riverbed an promise not to litter your great blog entry with too much spam :)

    I do want to point you to the performance hall of fame contest where Riverbed customers are sharing their performance results. You can check it out here http://www.riverbed.com/halloffame

    Cheers,

    Bob Gilbert
    Riverbed
    [email protected]

  12. Michael Leonard said:

    Hi, I'm in marketing at Cisco for WAAS, our WAN Optimization solution. We are seeing a lot of uptake as customers consolidate branch office servers to the data center. WAAS has a number of features, such as transparent network integration, that preserves services on the network, and a module for the Integrated Services Router that brings down the total cost of ownership that you might want to look at.

    read our blogs here: http://blogs.cisco.com/datacenter

  13. Adam said:

    One of the popular usage scenarios of WAN Accelerators is RDP acceleration. In addition to hardware solutions, there are also lower-cost software solutions for such a requirement. Ericom Blaze is a software based RDP Accelerator which can work standalone and also in conjunction with WAN Accelerators and add a lot of value to the network.

    Ericom Blaze has three main advantages over general purpose hardware-based WAN accelerators: performance, security and price.

    Ericom Blaze provides better performance for RDP because it was custom designed for it - Blaze introspects the RDP protocol and applies dedicated optimizations. For example, Ericom Blaze identifies images transmitted inside RDP and applies dedicated image compression algorithms to them, and in addition applies bulk compression to the entire RDP data stream. General purpose WAN accelerators only apply generic optimizations such as bulk compression and caching.

    As a result, a leading WAN accelerator vendor claims 12% to 38% RDP speed improvements, whereas Blaze can compress RDP by as much as 98.7%.

    Blaze takes care of the RDP choppiness while network appliances do not. If you display a movie frame with Blaze, it will display it as a single frame, providing native PC-like presentation, while network appliances will just compress the traffic and the Microsoft RDP client will still display a choppy frame (the frame will display in tiles).

    Ericom Blaze provides better security for RDP than general purpose WAN accelerators because these hardware solutions require RDP’s own encryption to be disabled so that they can compress and cache it. As a result, the communication from the RDP host to the server-side hardware appliance, and from the client-side hardware appliance to the RDP client is not secure. Only the communication between server-side appliance and the client-side appliance is encrypted.

    Ericom Blaze is installed directly on the RDP host and RDP client, and provides end-to-end encryption for complete security. Also, Ericom Blaze can work with both encrypted and unencrypted RDP.

    Ericom Blaze is less expensive than hardware-based WAN accelerators because it is a software-only solution, and does not require specialized hardware.

    To top it off, Ericom Blaze is very easy to deploy and install, and usually does not require any configuration. In most cases, Ericom Blaze can be downloaded, installed and ready for use within minutes.

    Read more about Blaze and download a free evaluation at:
    http://www.ericom.com/ericom_blaze.asp?URL_ID=708

    Adam

  14. Playing with a WAN Optimizer | Standalone Sysadmin said:

    [...] years ago, I asked for advice on WAN Acceleration. Let it not be said that I never follow up on [...]

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*