The concept of file caching has been around for many years. In fact, it’s one of the ways that IBM made its PS/2 Model 50 computer perform better than its predecessor, the IBM AT, even though the AT’s hard drive was actually faster than the PS/2’s hard drive. Today’s computing platforms use caching at many different levels. The file system is cached in hardware at the drive controller, then again in memory by the operating system; MAC and DNS addresses are cached; memory is cached on microprocessors; Web files are cached by browsers; and the list goes on and on. The BranchCache feature in Server 2008 R2 is a large-scale “macro” application of the caching concept. The idea is that a branch office, separated from corporate HQ by slow and/or intermittent WAN links, should cache file content requested by users so that it will not be necessary to traverse the WAN in the future to retrieve the same content. To use this feature, you must be running Server 2008 R2 on the file servers or Web servers whose content is to be cached, and Windows 7 on the client systems in the branch office. If you decide to cache content in the branch office on a server instead of on clients, then that server, too, must be running Server 2008 R2. The two modes of operation are “distributed” mode and “hosted” mode. In distributed mode, which to me is (at least conceptually) far less desirable, the Windows 7 clients do the initial caching of requested data, and they also do the sharing of that data to other Windows 7 clients making subsequent requests for the same content. Distributed mode can only work across one subnet in the branch location and it obviously breaks down when clients containing cached content go to sleep or are powered down. “Hosted” mode uses a server (which does not have to be dedicated to the caching function) to act as the file cache. Windows 7 clients requesting data from a central office get identifiers instead of actual data, then the clients check with the BranchCache server to see if the data is there from a previous lookup. If not, the client gets the actual data from the central office, and subsequently provides the data to the BranchCache server for storage, in the hope that some other Windows 7 client will need the same data later. Will this mechanism actually improve file retrieval performance? It will depend on a lot of factors, not least of which is the degree to which the exchange of identifiers can occur quickly and efficiently. There’s also the bandwidth available in the WAN link, and probably most important, the frequency with which multiple users in a branch need the same content from the central office. With a high percentage of unique data requests, BranchCache might not provide much of a boost, and could conceivably even slow things down. However, the principle of data caching is time-tested. For branch offices that do a lot of repetitive content retrieval, it might be worth a try – as soon as you’re running Windows 7 on all your clients.
Server 2008 R2 and BranchCache
Improving file access performance for remote offices
Copyright © 2009 IDG Communications, Inc.