I have yet another story up today about the AutoCAD issue with WAN optimization products. This time, Riverbed did some testing and had Taneja Group validate it. That story is here.

In the meantime, space limitations made it impossible to include the entire response we got from Silver Peak’s director of marketing Jeff Aaron in the story, but here is more of what he had to say:

From: Jeff Aaron
Sent: Thu 5/1/2008 8:38 PM
To: Pariseau, Beth
Subject: RE: Beth Pariseau’s latest article on AutoCAD issue

Hey, Beth.  The numbers that Riverbed quotes in their report for Silver Peak don’t jive [sic] with numbers we’ve seen in-house, in the field, and in tests done with AutoDesk.  I am not sure if they configured our box incorrectly or if there are some other factors at play.  The fact that we show negative data reduction in some examples and that Riverbed comes in first in EVERY single test should be the first indicator that these results are biased and incorrect…

I don’t see much value in going through the results line by line to point out inaccuracies as that will just continue to propagate the “he said” “she said” scenario.  Furthermore, lab results are meaningless as there are dozens of variables that affect performance in live networks - including bandwidth, latency, loss, and whatever other applications are sharing the link with AutoCAD.  That having been said, we only care about how we perform in real customer networks, and are comfortable that our claims will stand up if any end user decides to put us to the test (just like AutoDesk did).  To that end, we encourage anyone concerned about AutoCAD performance to give us a try and see for themselves.

Just wondering - what exactly was Taneja’s role in this?  They have never seen our boxes and have no hands-on experience with WAN optimization, so there is no way that they are capable of “verifying” anything about our product.  Who confirmed that our boxes were correctly deployed (we certainly didn’t)?  Who verified that the same tests were run on each vendors appliances in the exact same environments?  …   Make no mistake - this is a Riverbed report with jacked-up numbers - this is by no means a valid 3^rd party verification.

A little context for the section below: Aaron had also pointed out to me that Riverbed will struggle with more recent versions of Microsoft Excel files, which he says also do some bit-scrambling. Riverbed responded that he was referring to an issue with overlapping opens of Excel files which was fixed a long time ago.

Re. Excel - we provided a “diff file” that illustrates how the bytes are being scrambled from one save to the next (without any modifications).  It is clear from that that there is a scrambling issue that is similar to what is happening with AutoCAD.  My point is not to dispute what Riverbed can or cannot do wrt to Excel (even though the problem they said they fixed is a completely different issue).  My only goal was to point out that it demonstrates a data scrambling problem that is similar to AutoCAD, and that we don’t seem to be affected by it.

That is also why I keep referring to other applications, like Citrix and video streaming.  My point is to show that we handle these applications very differently than other dedupe vendors. What are Riverbed’s thoughts on that?  That is the bigger story, in my opinion.  AutoCad is just the latest symptom of a bigger problem - that there are different application types that fundamentally behave differently across the WAN, and you need the right architecture to address ALL of them…

Thanks for giving me a chance to comment.

Jeff

One of the common questions I am getting from IT people that I meet with is how can they protect remote offices, typically those with no local, at least officially anyway, IT staff. It is important to accept upfront that you may need a couple of solutions to address this challenge. This is especially true if you have remote offices that vary in size. There may be local databases and, more often than not, local file servers.

The first option is to eliminate the problem by eliminating the local need. Products like Citrix or Windows Terminal Server can eliminate the need for local applications and a wide area file system (WAFS) can eliminate the need for local file servers. The Citrix/Windows Terminal server solutions are best explained by those two companies so we’ll spend our time on WAFS. WAFS essentially places a cache at the remote site. At a high level, this cache is a server appliance with a small local disk that can replicate changes as they happen to a central server at a primary data center. The most frequently accessed data is stored on the remote file server, which serves up data to those users in a local fashion and at local performance. Typically, proprietary but enhanced network protocols are utilized to get higher performance on data transfers for data that is not in the remote cache. Some of the WAFS companies are also providing the ability to utilize data deduplication on the network, in a similar fashion to how some disk-to-disk backup products use data deduplication to optimize storage. NAS that can do data deduplication would be an ideal central NAS for this environment since typically there is a high level of file redundancy between remote offices and the primary data center.

From a data protection standpoint, the centralized repository for all the remote cache’s data is now also a server at your primary data center and can fall under the umbrella of your normal protection scheme. Other advantages to WAFS is that it can eliminate the need for buying additional servers and storage for remote offices, delay the need for bandwidth upgrades and can even enable better collaboration between offices.

Another option is to use replication. This is ideal for sites that in addition to a remote file server also have some remote database applications or email, especially if there are just a few of this type of sever present. While most data replication products are considered for disaster recovery solutions, they also make for an ideal remote or branch office backup solution. With these products all data is replicated as it changes to a centralized disk at the primary site. This disk can then be mounted to a backup server and backed up locally at the primary data center. Cost can be a concern if the local server count is more than just a few servers and you are not leveraging the other value points (disaster recovery and failover) of replication. Also, unless your data replication solution can produce snapshots to freeze moments in time or you can leverage snapshot technology by replicating to storage that supports it at the primary data center, be aware that if you do experience corruption at the remote site, you will then very quickly replicate that corruption to the primary site.

If you don’t need the near instant protection of WAFS or replication you can also leverage some D2D solutions to perform a backup locally and utilize the D2D solution’s replication capability to send that data to a similar device at the primary data center. This typically makes sense when you have a fairly large data set or number of servers and maybe a small remote IT staff. It will also almost certainly require a data deduplication device, as straight disk-to-disk backup will not work well for remote backups. You need to be able to deploy a D2D solution that can leverage data deduplication. Standard backup to disk essentially consists of several large backup files. Those files are typically created too fast and are too large to be copied across the common WAN segment in time to meet the nightly backup window. Data deduplication appliances on the other hand only have to send the changed block between the backup jobs, greatly reducing the WAN requirement. Also, you now have the data locally at the branch office instead of only at the primary data center, allowing for faster recovery at the branch if needed.

In the past four or five years, we have expanded from hardly any options for remote office data protection to many. Which of these solutions you deploy is a function of budget and business requirement, and in some cases it may make sense to blend the solutions. Assessing the needs of the remote offices while focusing on the business realities at the primary data center, will help you make those choices.

For more information please email me at georgeacrump@mac.com or visit the Storage Switzerland Web site at: http://web.mac.com/georgeacrump.

TechTarget’s networking reporter Andrew R. Hickey wrote an insightful piece on WAN optimization technologies embedded in Microsoft Windows Vista and Longhorn Server and how they could make separate WAN optimization boxes obsolete:

Vista and Longhorn contain redesigned TCP/IP stacks, quality of service (QoS) facilities, file systems, security systems, and WAN-friendly presentation layers for applications…TCP flow control and error recovery have been improved while remaining compatible with other TCP implementations… Microsoft has enhanced management control over QoS, meaning that network administrators might be willing to trust QoS markings from Windows machines. In addition, the native Windows file-system access protocol, CIFS, has been improved and will work with most existing applications without requiring program changes. Also, remote application delivery systems, like Windows Server Terminal Services or Citrix Presentation Server, will probably have their performance enhanced when applications are rewritten to use Vista’s Windows Presentation Foundation component.

Before you go chucking your Riverbed box out the window, though, there are a few caveats:

Vista’s security improvements interfere with some VPN clients, and certain security options could interfere with existing WAN performance or optimization products unless they’re disabled. Data-reduction compression done by external WAN optimization tools may still be very useful in some situations.

[…]

Enterprises should use caution and examine how compatible Microsoft’s technologies will be within their networks, according to Gartner.

“Windows Vista and Longhorn offer the promise of improved networking performance and security,” Gartner stated. “However, the scope and scale of the changes present significant security and compatibility risks. Most enterprises will delay large-scale deployments until after application compatibility has been verified, which Gartner expects to take 12 to 18 months. This will give networking components time to mature…. As a result, the benefits of the new Windows communications stack will not be broadly realized before 2009.”

For now, maybe try tossing a TV off the roof instead.