mailing list archives
Re: riverbed steelhead
From: James Michael Keller <jmkeller () houseofzen org>
Date: Mon, 25 Apr 2011 15:30:16 -0400
On 04/25/2011 01:55 PM, Andrey Khomyakov wrote:
I personally would take Riverbed over Cisco for one main reason that I have
discovered when I was researching them (that was good 3-4 years ago and
cisco may have "improved" since).
Yes, they have improved dramatically in the last few years since the 4.x
Cisco "accelerates" based on application. That is to say if it's not a well
known application protocol, they do not do anything with it.
So, they are probably good for HTTP/FTP/Samba etc.
Riverbed does not care for applications (they still support application
based acceleration, but they also support non standard stuff). They take
something along the lines of data hashes and store them (along with data of
course). They just store raw bytes as opposed to a let's say a file. That
played out well when I had to make a decision about which brand to purchase
for the company that had a homegrown application. So in a nutshell, Riverbed
improved performance of that application (as well as all the standard
players like HTTP/FTP etc), while cicso said outright that they won't.
The current gen of WAAS works this way as well. The accelerators are
configurable for defined services along with a default profile. There
are several accelerators that are applied to each connection, starting
with the most basic TCP session optimization for window sizes and other
per packet modifications.
It then applies raw data optimizations such as the raw 'bit' database
you mentioned, each WAE will attempt to find the largest unique run of
bits and create a hash for that sequence and store it in it's local
database which decays based on time and hit count. If both WAE's in
the path have this hash that is all that needs to be sent, otherwise it
sends the entire payload, which will then be cached on the second WAE
going forward for repeat occurrences (cache expiration not
withstanding...). It can also do LZ compression on the full payload
when it needs to send it.
After that there are application protocol accelerators for common
protocols like CIFS, HTTP, etc. These work on the session level and
act as transparent proxies for the protocols and can include file
cache's on the WAE. For other protocols like MS Video live streams, it
can turn a uni-cast session from multiple clients into a single session
up to the video server instead of multiple connections from each client.
You also have the option with these to push server certificates and
private keys into the WAAS system with the Central Manager, which allows
transparent SSL/TLS acceleration for internal applications along with
encrypted local storage on the WAEs.
As an example, we had a commercial patch deployment system that would
bog down on patch days or large updates like services packs. After the
WAEs went in it improved a bit but was still a huge tax on the network
even with sites that had local deployment servers for this
application. After digging through the application traffic it was
actually deploying with an HTTP server running on a high port. So we
defined a new protocol in the CM for this port (you can also include
src/dst in the configuration to narrow matching if needed). Now after
the first download at an office location, the follow on requests as
folks come into the office and power up are all served from local cache
on the WAE.
Now that's if you are running something it does have an application
level accelerator for, if it's some other protocol you can either take
the default or enable or disable some of the packet level
optimizations. For example, if your traffic is encrypted - it would
make sense to disable the LZ and bit database processing and just leave
the TCP session optimization enabled, since the processing time to do
the compression will actually take longer then just transferring the
original payload and also may be causing the packet to fragment and
double the number of packets required, etc.
After purchase, we saw a dramatic improvement in "user experience"
(basically the complaints stopped) from our EU site that was accessing
windows (samba) based file servers in USA. Those guys at the time were
connected to the US office over MLPPP (4 T1s). Samba sucked for them along
with everything else.
Yes, deployment of most WAN accelerators that will do file caching will
if not gain love from your users, it at least gets them off your back.
The only issue I had with Riverbed is their licensing model feels very
backwards. It took me a while to understand what we needed.
On Thu, Apr 21, 2011 at 10:36 PM, Jonathan Fernatt<fernattj () gmail com>wrote:
On Thu, Apr 21, 2011 at 2:49 PM, harbor235<harbor235 () gmail com> wrote:
Anyone out there have experience with Riverbed Steelhead products?
Do they improve TCP performance over WAN links? is it worth the price?
I've had good experiences with both Riverbed Steelhead and Cisco WAAS
products. Both have a very short ROI. I think either are well worth the