Riverbed Technology's Steelhead 2.0 Appliance

I labeled one Steelhead the "data center" and connected its LAN port to an SMC TigerSwitch 6752AL2, which was also connected to data center resources housed in a Dell 1650 computer and in a Rave Computer UltraSPARC IIi server. The Dell sported a Windows 2003 Server with Microsoft Virtual Server 2005 running a Domain controller, Exchange Server 2003, a Microsoft SQL 2000 Server and a file server. The Rave Computer ran Solaris 9 and was dedicated to serving HTTP and FTP files.

I labeled the other Steelhead "client center" and plugged it into an Extreme Networks Summit48 switch, attached to clients in a simulated branch office that made requests to servers in the data center. Traffic is optimized between the Steelheads in both directions, and whether clients were requesting or receiving data, the Steelheads compressed and sent the data over the WAN link without a hitch.

Smart, Speedy Transfers

In my tests, data traversing the WAN link for the first time had improved performance of 60 percent to 90 percent, depending on the file type. But the real story here is what happens after that first pass, when data passes through the Steelhead for a second time--that's where SDR (Scalar Data Referencing) comes in.

SDR lets one Steelhead appliance keep track of data passed through it and across the WAN to another Steelhead. So when a client sends or receives an original data request over the WAN and the data passes from one Steelhead to another, the receiving Steelhead saves the data on disk and returns reference pointers, down to the byte level, to the sending Steelhead. The next time those same bytes are requested over the WAN, the sending Steelhead identifies the duplicate bytes and sends only the changed bytes.

The effect--a reduction in the amount of data traversing the WAN--lets clients retrieve data from a local Steelhead at lightning speed. The results are amazing. In my tests, after data went through a Steelhead the second time, response time was so quick it was like requesting data from a local disk for small files--less than one second. For larger files, it was like requesting data from a remote disk on the LAN.

No Cache

Steelheads do not serve client requests from hard cache like the Peribit SM-250 (now owned by Juniper Networks and renamed the WXC application acceleration platform) does. If a back-end server goes down, there's no original data for a Steelhead to send as duplicate data. If you need to preserve data in the event of a WAN outage, look to Riverbed's PFS (Proxy File Services).

I set up PFS for employees on the local Steelhead appliance and shut down a back-end server. These users could quickly access their stored files on the appliance, just as they could from a remote file share. In the background, the local Steelhead synchronized that data with a back-end file share using Riverbed's RCU (Remote Copy Utility) and SDR.

Next I saved a 593-KB file to the PFS directory on the local Steelhead. Then I reopened the file and added data, making it into a 601-KB file. After engaging manual synchronization, only 25 KB of data traversed the WAN link (see "Upping Uptime"). High-Speed TCP

Slow WAN links abound and some of these suffer from high latency (round-trip delay). If that's your situation, Riverbed has an answer in HSTCP (High Speed TCP). In this mode, two Steelheads can increase throughput and fill up a data pipe, maximizing WAN utilization.

I easily set up HSTCP over the Web interface. I checked a box for each of the Steelheads and increased the LAN buffer size to 1 MB. Then I increased the queue size on each of the WAN interfaces to 1,250 KB and set a rule to pass data through the Steelheads unmodified, without compression or SDR. Once this was set, I fired up a client with FTP to transfer files from the Rave Computer. I increased throughput from approximately 183.5 KBps without HSTCP to a maximum of 7,533.56 KBps with HSTCP, before the server hit its CPU limits. I tried the Dell 1650, a less CPU-bound machine, and was able to transfer 10,956.55 KBps.

HSTCP is for big pipes with high latencies and beefy servers. With HSTCP enabled, you won't get the benefits of compression or SDR to reduce bandwidth utilization. But if this fits your scenario, a couple of Steelheads will bring your data to the data center fast and possibly complete that remote, overnight backup on time before your users get to work.

Sean Doherty is a senior technology editor and lawyer based at our Syracuse University Real-World Labs®. Write to him at [email protected]. I set up Riverbed's PFS between the simulated data center and branch office. On a central server, I installed Riverbed's RCU (Remote Copy Utility), which is similar to Window's Robocopy utility (found in the Windows 2000 Resource Kit). Riverbed's RCU, like Robocopy, depends on CIFS APIs to transfer files and entire directories over slow WAN links. But unlike Robocopy, the RCU facilitates file transfers over slow WAN links by minimizing the number of round-trip handshakes and providing delta transfers--in other words, it sends only modified data blocks.

Next, I set up two file shares on a Windows Server 2003 and set ACL (access control list) permissions to limit access by domain user and group. From the Web interface, I enabled PFS and supplied Active Directory information such as the FQDN (Fully Qualified Domain Name), Domain Controller name, and a Domain Administrator login and password. Then I added the UNC to the shares. Once that was done, the Steelhead authenticated to the Domain to link the back-end file shares and make them available to remote users from a local Steelhead appliance.

I used one of the shares in broadcast mode. Then I made single files available to multiple users by copying them to the data center share. Once there, the data center copy was synchronized across the WAN to the remote Steelhead. In effect, all branch office users who had access to the back-end share now had equal access to the share residing on the local Steelhead. For the other Windows share, I limited access to one user's account to emulate a home directory. There is also a one-way file transfer to back up a local data store on the Steelhead with a central office server. That "stand-alone" operation overwrites files on the central server but does not synchronize them.