WAFS: Building a Better Pipe for Remote Locations

The concept of "WAN optimization", which we discussed last week, doesn't cover everything you need to know about connectivity outside your own network. Most notably, Wide Area File System, or WAFS, is a specific technology designed to optimize WAN-based file system performance. This article, continuing from last week's WAN optimization overview, will explain how WAFS can minimize costs in branch offices.

WAFS is intended to facilitate implementations of the desirable "serverless remote office," which doesn't require skilled admins on-site. Even fairly large sites can get by with low skill and low cost PC support personnel, instead of keeping IT staff on-site. Centralized IT services also imply that remote sites don't require backups, data protection, or anything else.

The idea is to configure remote systems for server-based operation. This can mean many different things, so we'll keep the terminology vague. Local PC's connected through Windows Active Directory will work, if users are trained to store files on remote shares. Other configurations are possible, and varying levels of centralization are suitable for a variety of situations. Simply placing applications on fewer servers can save on software licenses, in some cases a significant amount of the remote office's budget. In the ideal case, where file services can be centralized, cost savings are extreme. A central office can likely absorb storage costs, including backup and disaster recovery.

Regardless of what specific design is required, the real news here is that WAN file access can be implemented without purchasing a faster Internet pipe.

These new technologies enable the remote office to send and receive data over much slower links than ever before. In the case of office workers, the Microsoft Office example is still a great one. Opening any recent Word or Excel document can take literally 10-100 (or more) file system reads, even for the most trivial of document types. The CIFS protocol itself is quite inefficient. Coupled with a slow WAN link, opening an office document can be an exercise in patience.

Multiple tricks, services, features, or however they are marketed, allow WAFS to make remote sites feel like they're in the same building as their servers. One function of WAFS optimizations is to cache files. A corollary to this is that WAFS can also optimize certain protocols, by terminating connections locally and acting as a broker between local systems and a central server.

File caching, arguably the primary function of WAFS, provides tremendous benefit. Say everyone in the office is going to open the same 100MB file a few times per day, and maybe only one person is writing to it. The WAFS device will store the file locally after the first time it has been transferred to the remote site. In the case of large files like this, the WAFS box will likely have disk cache, but even memory-based caching configurations can provide significant improvements for a diverse set of applications. When the person or persons who need to change this 100MB file save the data, only the changed parts of the file really need to be transferred back to the central server.

Caching blocks of data is fairly straightforward, but synchronizing them cannot be done with most network file systems. Most WAFS implementations, most notably the Cisco one, actually do optimize the CIFS protocol. To optimize something, you generally need to use it differently than its intended case. This is an example of the second part of WAFS: spoofing the protocol at the network borders, and doing something smarter in between.

Terminating protocols locally and using smarter protocols instead is essentially the same way generic WAN optimization works too. Only, this is at layer 7, and WAN optimization, the general term we discussed last week, operates at layer 4.

Since WAFS devices understand the underlying protocol, greater speed improvements can be realized over generic TCP/IP optimizations. As with any attempt to monitor, optimize, analyze or aggregate, knowledge of the actual protocol being used on top is required to operate effectively. WAFS can yield such improvements in speed that users may not even realize their applications are being served over a WAN, but the question remains, "should you do it?"

Yes and no. The obvious drawback is that if your central application or file servers go down, then every remote site feels the outage at the same time. If these services are redundant and resilient, "single point of failure" isn't a very strong argument either for or against WAFS. There is another point of failure, though: the remote office's WAN link.

If remote office uptime is mandatory, the WAN link cannot be a single point of failure. If short outages are acceptable, then the benefits far outweigh the risks. For remote offices that require access to these file services in order to operate, WAN redundancy is a must. Generally these sites will already have reliable and redundant WAN access anyway, because chances are they need some services from the central office already.

In short, the decision to make serverless remote offices should be carefully weighed against the service level requirements for the remote office.

WAN Optimization and WAFS technologies are still growing, and the rate of adoption is beginning to grow as well. Remote offices can certainly benefit from these services, if carefully deployed.