Get a Head Start on NT 5.0 with Dfs

It's 3 a.m., and my Washington, D.C. server just crashed. A few thousand important Word documents are on that server. But I'm not worried. The reason I'm not worried is that I protected all the critical shares on the server with Microsoft's Distributed File System (Dfs) technology. The Los Angeles, California server will service all user requests from its replica of the Washington, D.C. data, without the users even realizing it.

Although this scenario is a figment of my imagination, the Dfs technology is not. This technology is currently available for Windows NT 4.0 and will soon be available as part of NT 5.0. Dfs will revolutionize the way you distribute files and shares across an enterprise network. By taking advantage of Dfs in your network, you can increase your enterprisewide fault tolerance tremendously.

What Is Dfs?
According to Microsoft's Dfs documentation, Dfs implements one name space (or directory tree) for disparate file system resources in an enterprise. You can think of Dfs as a tool that creates a network share that is full of other network shares, either on the same server or on other servers. By publishing shares in a Dfs directory tree, you can logically organize network resources that are physically in different parts of the world. If you organize the resources in one hierarchy, your users can navigate through these resources as easily as they can click through directories. (For an introduction to the organizational strategy of Dfs, see Sean Deuby and Tim Daniels, "Dfs: A Logical View of Physical Resources," December 1996.)

In addition to centralizing important shares and directories into one hierarchy, Dfs provides fault tolerance and intelligent load balancing by maintaining replicas of essential data on multiple enterprise servers. If one share can't service a user's request, another one simply picks up the slack without the user knowing it.

How Do You Implement Dfs?
Implementing Dfs in a network is easy. Because Dfs isn't a new file system, you don't have to reconfigure existing systems to implement it. In addition, Dfs doesn't affect the NT standard file system's processes. For example, Dfs doesn't alter the NT's permission verification process. If a user doesn't have the rights to access a particular share or file, navigating to it through Dfs will not make a difference. The user still won't be able to access it.

All you need to do to implement Dfs is follow three steps: Create a root directory, add shares, and replicate important data. For example, suppose I want to set up a Dfs tree for the domain in my opening scenario. As Figure 1 shows, domain NETARCHITECT has two servers: WASHINGTON and LOSANGELES. Here's all I have to do to implement Dfs in this domain.

STEP 1: Create a root directory. Because every directory tree must have a starting point, I first create a root directory called DFSROOT on the WASHINGTON server and share it under the same name. Next, I use the Dfs Administrator utility to define a new domainwide Dfs tree, as Screen 1 shows. Then, I simply select the share to publish as the root, as Screen 2 shows.

I now have an empty root directory for a Dfs tree. This root directory isn't very interesting, but how I use Dfs to get to this directory is. I must use a universal naming convention (UNC) path that references the name of my domain instead of a specific machine. Although the true root of the Dfs tree is at \\WASHINGTON\DFSROOT, the way I map to it through Dfs is \\NETARCHITECT\DFS.

STEP 2: Add shares. Now that I have a root directory, I need to add shares to it and point those shares to resources across my network by editing the properties of the Dfs root. In Screen 3, I'm adding the \\WASHINGTON\CONTRACTS share as a subdirectory called WASHINGTON in my Dfs tree. The Dfs path to access this share is \\NETARCHITECT\DFS\WASHINGTON.

When I add shares to the Dfs tree, I don't have to keep the original share name. I can choose any name I want. This flexibility is particularly useful for resolving enterprisewide naming convention issues.

STEP 3: Create replica sets of important data. Because the CONTRACTS folder is important in my network, I create a replica set for that data. I place a duplicate of the entire directory on the LOSANGELES server by copying the data into the share at \\LOSANGELES\DC-CONTRACTS. Then I add alternative location information for the existing Dfs entry by editing the properties of the \\NETARCHITECT\DFS\WASHINGTON share. As Screen 4 shows, I use the Add Server dialog box to specify the alternative location \\LOSANGELES\DC-CONTRACTS. With this replica set of data, users can access the files in the CONTRACTS folder, even if a server goes down. Figure 1 depicts this configuration, showing how two servers can publish shares into a directory within a DFS structure. The dashed line depicts the File Replication Service (FRS), which I will discuss later. The arrows depict the individual servers publishing their shares into the Dfs structure.

   Previous  [1]  2  Next