Area file services wide

Webopedia Staff. November 29, Updated on: May 24, Wide area file services, or WAFS, is a storage technology that allows businesses and enterprises to access remote data centers as if they were local. WAFS allow multiple agencies to manage data , data archiving and wide area file services products and provide a combination of distributed file systems and caching technology to allow real-time, read-write access to shared file storage from any location.

A wide area file services is an alternative system to a wide-area network WAN. For more information on current editorial staff, please visit our About page.

Top Articles. We look at the history of Windows Read more. Website Shortcut on Your Desktop reviewed by Web Webster This Webopedia guide will show you how to create a website shortcut on your desktop using What are the Five Generations of Computers? Reviewed by Web Webster Learn about each of the 5 generations of computers and major technology developments that have led to the computing devices that Launched in , Hotmail was one of the first public webmail services that could be accessed from any web browser.

At its peak in Related Articles. Lucas Ledbetter - January 12, 0. Reference The Complete List of From A3 to ZZZ we list We also spent time in the lab with Signiant Software's product, only to determine it was not a good fit for this review. All WAFS products require two appliances: one on the client side and one on the server side. In addition to performing decompression and caching, the client side box compresses data on its way to the data center.

The products we tested use two different architectures see diagram below for a comparison of setups. Juniper and Expand support an inline implementation that lets you set up a route through the two boxes to get to data.

This way all traffic between the sites is cached, routed and accelerated automatically. The appliances typically come in two sizes: The smaller units emphasize low cost and is intended for remote offices, while the larger is built for performance and is intended for a data center installation. With the second architecture, supported by all three vendors, you can put the appliances on the respective networks one remote, one local , but not directly in the data path. The devices are configured to act as proxies for remote shares, and drive mappings are changed to point to the local appliance instead of the remote servers.

When a user accesses a file from the share, the two appliances work together to make certain the user is getting the newest version of the file--and the cache is updated as needed. Working with the Expand and Juniper staffs, we tested their appliances using the inline implementation.

Some users may prefer to avoid an inline solution because of performance concerns. However, the products from Juniper and Expand easily perforrm well enough to use in an inline configuration. These products work by caching file data blocks. When files are accessed, only changed blocks are sent over the WAN--the rest of the file is fetched from the local cache.

Pinning vendors down on the details of chunk size and mutability was difficult. In the end, we realized this kind of information is part of their secret sauce and they weren't going to reveal the details.

Finally, we focused our tests on file services, but it makes sense to take advantage of all the functionality these products have to offer, including application acceleration and WAN acceleration for more on these topics see " More Than Just Files ".

It wasn't always the fastest accelerator, but when you add in-depth reporting, reliability and ease of use on the user end, it stands out as the clear winner. At some point, milliseconds are not relevant to user experience--in fact,in most cases where Juniper was not the fastest, the difference was negligible--so small that we suspect users wouldn't even notice.

Its outstanding feature is its invisibility to end users. Because the product works inline and all network traffic streams through it, you don't need to remap drives or set up separate accelerated folders. The user experience doesn't change, except that it is much, much faster. Juniper also won the reporting category hands-down--its reports range from raw transfer volumes to a CIO dashboard.

During our tests, we discovered that the inline architecture does make configuration and administration difficult if the two boxes aren't communicating, causing several problems for users. Changing the IP address of one of the Juniper boxes is a bit painful, but not impossible. If you're planning to change IP addresses, schedule some downtime with a technically savvy IT person at the remote site to support your efforts.

With compression, duplicate elimination and acceleration, the WXC appliance crunches your data into small tasty chunks through several layers of software.

Quality of service is what you'd expect. During our tests, the device provided acceleration ratios as high as 15 times the baseline, and the difference in time saved transferring files between "warm" cache hits and "cold" uncached data access is astounding--an 11x multiplier for our monster 1-GB TIFF file. Expand Networks Accelerator Although this device's QoS is standard and the system performs well enough, it left us with the impression that it isn't as mature as Juniper's product.

For instance, the appliance requires that some data be "prefetched"--transferred before users attempt to access that data the first time. When our 1-GB test file failed our tests, we discovered with a little help from Expand that large files--large being relative, based upon size of pipe and size of file--must be prefetched.

Expand told us that this is only a problem with test labs, but we find that rather hard to believe. Our file, while large, is no larger than photo-processing, GIS and engineering companies generate on a regular basis. In addition, the version we tested could only "prefetch" entire volumes through the Web user interface, though the underlying system could prefetch individual directories. Expand assured us this would be fixed in a future release.

Unfortunately, even after the prefetch indicated that our 1-GB file transfer was finished, we still received errors testing against that particular file. Expand says this isn't normal behavior, and we're working with the company to determine the problem.

We will blog the results when we discover the root cause of the problem. If you don't generate large files, this probably won't be a problem for you. But we would sleep a little better if Expand could tell us exactly how big is "too big," since many marketing slide presentations can grow this large.

We saw this problem with files as small as KB, but in a slightly different context--the OS reported "file not found" on first access, but then present the file on subsequent accesses. There were a few other glitches with Expand's implementation.

Inaccuracies in its reporting caused us to question the device's throughput. Of course, for this review we counted on our own timing and throughput mechanisms. However, in daily use, those reports would start to grate on responsible managers. One report, for instance, showed that accelerated throughput was less than base throughput--though our independent timing clearly indicated that this wasn't true. This has some appeal. You can always bypass the appliance by going directly to the source--if you're willing to put up with the performance hit that entails--but it also causes problems for end users who may confuse the appliance with the source server.

Since users will adjust, and the ability to bypass the appliance should something go wrong is a benefit, this system works well overall. Tacit's Windows-based product has some advantages over the others. Tacit also offers a Linux version, but we tested only the Windows product.

It is easier to configure the Tacit appliances because you can hook a console up to them and modify them like any other Windows system.