Dfs

Today’s networks began in the 80’s as nothing more than a cost-effective means of sharing expensive file and printing resources amongst a number of users.

Disk storage was extremely expensive, and so a single file server with a 2GB hard disk made users feel as though they had all the space in the world available for their files. As companies added to their networks, more and more file servers appeared, each with multiple disks, in order to grow the storage capacity to cope with new application and data requirements.

The problem was, that users had to be aware of the physical location of their data files on the network – or else network administrators had to set everything up so that the users didn’t HAVE to know. Individual servers and shares were referenced by a notation known as Universal Naming Convention (UNC) which takes the form�\\server_name\share_name\path\file_name. Although UNC can be used directly to refer to a particular share, it is more common to find long and complex UNC names mapped to single drive letters using Windows Explorer or the NET USE command. Thus, the directory \\SERVER1\PAYROLL\DATA might be mapped to drive X:. A user could then refer to this simply as X: from then on, and sub-directories off that share could be accessed just as with a normal drive – X:\LEVEL1\LEVEL2\……\FILE_NAME, for example.

As networks continued to grow in size and as organisations began to use existing storage, both internally and externally, for purposes such as intranets, it became apparent that the idea of mapping a single drive letter to individual shares did not scale well. And despite the ability for users to directly reference UNC naming, the true nature of the problem is that end users can become overwhelmed by the increasing number of places that must be accessed in order to retrieve data.

You can sympathise with the poor user that has access to several different applications, each with its own data store located on different disks and different servers, sometimes spread across the globe. Sympathy is due for the poor administrator too, since he or she is the one who has to ensure that all of these data stores are backed up securely. A new application could mean yet another share on yet another server, and the administrator must include this in the daily backup regime.

Finally, what happens when one of those servers goes down for whatever reason? The data on that server is temporarily unavailable, and this renders any applications that depend on that data completely unusable for the period of the down time.

Microsoft’s Distributed File System (Dfs) solves all of these problems by permitting the linking of servers and shares into a simpler, more meaningful name space. Implemented as a server component that is an integral part of Windows 2000, with a version available for NT4 as well, Dfs permits shares to be hierarchically connected to other Windows NT shares. Since Dfs maps the physical storage into a logical representation, the net benefit (no pun intended!) is that the physical location of data becomes transparent to users and applications.

The main idea behind Dfs is a simple one in theory – you create a “share of shares”. You start out by creating a Dfs “root” which looks just like any other share on your server. However, you can then start to “publish” other shares within that Dfs name space, making it easy to build a single, hierarchical view of multiple file servers and file server shares on your network. Instead of seeing a physical network of dozens of file servers, each with a separate directory structure, users will now see a few logical directories that include all of the important file servers and file server shares. Each share appears in the most logical place in the directory, no matter what server it is actually on.

This makes life so much simpler for the end user. Dfs gives the user a single directory that can span a vast number of file servers and file shares, making it easy to "browse" the network to find the data and files needed. Server-level Dfs directories can be combined into a hierarchical Dfs directory, constrained only by the limit of 260 characters per file path. Browsing the Dfs directory is easy because Dfs sub-directories can be assigned logical, descriptive names, no matter what the name of the actual file server/file share is.

Dfs makes it easy to find data and files because the file search tools included in Windows 95 and Windows�NT Workstation, or even your word processor, can now search for a specific file that can be located on any server in the Dfs directory tree.

For instance, the user will now browser the Dfs root and see the ACCOUNTS share, within which will be the PAYROLL, PAYABLE and RECEIVABLE shares. This logical grouping of data hides from the user the fact that each of these shares resides on a completely different server. Hence, Dfs makes it easier for you to find and manage data on your network, since it unites files on different machines into a single name space.

Dfs support is already included in Windows�NT Workstation 4.0, and support for Windows 95 is included in the Dfs release. �With Windows 95 and Windows�NT Workstation, Dfs makes large, distributed networks easier to use, since instead of having to deal with multiple persistent network connections to separate physical file servers, each user only needs one or more persistent network connections to their Dfs trees. Additionally, with the Windows NT Client for Dfs, you can NET USE below the \\server\Share level. Another advantage of Dfs is that it is not limited to a single file protocol. Instead, it can support the mapping of servers, shares, and files regardless of the file client being used, provided the client supports the native server and share to begin with.

For the administrator, Dfs provides a useful tool for reducing the complexity of managing an ever-changing server configuration. As old servers are retired, groups of servers are consolidated into more powerful servers, and new servers are brought on line for the ever-growing storage requirements.

Dfs makes it easy for network managers to replace servers. Each node in the Dfs directory tree is assigned a logical name that points to a file share, and at any time the Dfs node can be switched to point to a new server while the old server is taken off line. Users will never know that they are using a different server, since the Dfs directory tree does not change.

Dfs can also provide enhanced data availability by pointing to multiple volumes which can be alternates of each other - if one is unavailable, Dfs will hand over to the alternate one. This also provides a performance gain because when all replicas are up and running Dfs can distribute client accesses to Dfs volumes evenly across multiple alternate network shares. If 300 users require access to one volume, Dfs can split the users among copies on two or more servers to balance the load.

Another advantage for the administrator is that Dfs makes file maintenance tasks such as enterprise backups easy. Since a single Dfs tree can be built to cover a large number of servers, the backup software can back up this single "tree,” no matter how many servers/shares are part of the Dfs. Dfs can also make backups of data on end-user systems easy. Windows 95 and Windows�NT Workstation systems can participate in a server-based Dfs volume appearing as "leaves" in a Dfs tree. This means a Dfs tree can include all the directories on users’ desktops that network managers want to include in the corporate backup regime.

At the application level, Dfs simplifies deployment of Internet and intranet solutions. A Web master can now build a logical Dfs directory that includes the default Web pages of each department’s Web server as a sub-directory of the main Internet or intranet Web. This allows each department or group to retain control over their unique intranet content and applications, while the user only sees a single, unified Internet site or intranet.

Although Dfs will work fine on NT4, it is designed to integrate closely with Active Directory under Windows 2000. Dfs can use Active Directory to store administrative knowledge of Dfs as well as to provide root level fault tolerance. Directory services can also be used to provide a site topology for providing intelligent replica selection, as well as to keep all participating machines in any Dfs root synchronised in their perception of the Dfs structure.

With Dfs, Windows 2000 will move a step closer to the ideal of providing true “network storage” rather than simply a collection of disparate and unconnected discrete data stores spread around the corporate WAN.

Send mail to webmaster with questions or�
comments about this web site.
Copyright � 1991-2002 The NSS Group.
All rights reserved.