Problems That Dfs Solves

An administrator can use Dfs to build a single hierarchical file system or a small set of them that extend across the enterprise. This logical representation of network storage allows the following:

• Use of a single namespace

• High availability

• Load sharing

• Capacity expansion

• Easier intranet and Internet publishing

Unified File System Namespace

As file servers crop up throughout the enterprise — often in a grassroots fashion — it becomes more and more difficult for users to find the information for which they are looking. Shared folders are often distributed throughout an enterprise on many file servers across a wide area network. Many organizations have hundreds of file servers throughout the enterprise. This presents the user with the problem of where to start looking for information. Because shared folders are usually associated with physical servers, the user must first determine what physical server is hosting the shared folder. For example, product information might be stored on \\Building 4\Marketing2\Prod_Info or on \\Corporate\Floor 4\Sales\Prod_Info.

An administrator can use Dfs to address this situation by consolidating a large set of physical shared folders into one or more logical namespaces. The underlying shared folders do not have to be modified in any way to work with Dfs. Dfs is a technology that changes the user's view of the physical storage. Dfs allows a unified file system namespace to be developed that masks the physical locations of the underlying shared folders from the users.

In the previous example, users might not necessarily know whether they must look on a Sales server or a Marketing server for the information they want. And even if they did, they might not know the physical name of the server. By using Dfs, an administrator can publish the \\Building 4\Marketing2\Prod_Info shared folder into a logical namespace called \\Company\ProductInformation, for example. Other entries in that logical namespace might be \\Company\Benefits, \\Company\Legal, and so forth — each of which might reside on a physically different file server or shared folder. The logical namespace can be built into a deeper hierarchy, so \\Company\Benefits\Medical and \\Company\Benefits\Retirement might also be added — and refer to different servers or shared folders as well.

Users no longer need to know the physical location of shared folders instead, they can browse through the logical namespace and Dfs transparently navigates them to the appropriate underlying shared folder.

Note that Dfs cannot solve all of the enterprise's naming issues nor can it catalog all corporate information. Dfs is specifically a solution that targets file systems. Other namespaces are still outside the scope of Dfs, such as public folders in Microsoft® Exchange Server client/server messaging and groupware, the Printers folder, and Active Directory. Dfs can work with some of these other technologies, but it is not meant to consolidate these disparate namespaces.

High Availability

Windows 2000 Dfs provides the ability to create multiple shared folders (called replicas) with the same logical name. This can be done at any point in the namespace hierarchy — at the root or at any point beyond. This means that when a file server or shared folder is brought down, either planned or unexpectedly, one or more other servers can still service a client's request for file data.

If a client has access to a shared folder through the logical namespace and the underlying physical resource is unavailable, Dfs automatically fails over to a replica. Dfs can be optionally configured to work with the File Replication service to maintain consistency in the data that is stored in a replica set.

Load Sharing

The ability of Dfs to support physically separate replicas with the same logical name provides a degree of load sharing. For example, suppose that \\Company\StockInfo is a heavily used sharepoint. This logical sharepoint can be associated with multiple shared folders on different computers even in different sites. Dfs allocates user requests to the underlying shared folders in a distributed manner.

Capacity Expansion

What happens today if your file server is running out of free space and the server is already at physical capacity? In most situations, you add additional disks to another server and create a new shared folder that is associated with the new storage.

As new shared folders are created to account for added physical capacity, the user has the added burden of first locating the additional physical servers and shared folders and then having to map additional drive letters to them.

You can use Dfs to expand a hierarchy beyond the physical capacity of the storage system by transparently linking to additional storage on different servers. In Dfs terminology, this is referred to as adding Dfs links. If you run out of storage on a server, you publish additional shared folders from another server into the logical namespace.

For example, suppose you have a shared folder named \\Sales\Info. Beneath the shared folder you have two subfolders, \Internal and \External. Physically, they are referred to as \\Sales\Info\Internal and \\Sales\Info\External. If the \\Sales server runs out of capacity and cannot be physically expanded, you are likely to install a new server (or use an existing one) and move some of the data to that server (called \\Sales2, for example). The result is that users would now need to know about two physical servers and shared folders to gain access to all the sales information (that is, \\Sales for internal information and \\Sales2 for external information).

You can instead use Dfs to eliminate this impact on the user. Suppose that before the server ran out of capacity, you published the \\Sales\Info shared folder into the logical namespace \\Company\Sales. Users would have access to the two folders as \\Company\Sales\Internal and \\Company\Sales\External. After the new server is installed, you can add \\Sales2\External to the logical namespace \\Company\Sales\External and leave the original link for \\Company\Sales in place.

The result is that the user still refers to the same logical namespace for these folders, but Dfs transparently connects them to different servers and shared folders. When your server ran out of space and you moved some of the storage to a different server, the user did not have to change anything.

Intranet/Internet Publishing

Another handy way to use Dfs is with Web publishing. With Internet Information Services (IIS), you usually set up a network shared folder as the location where content is to be served up by the Web server. This network shared folder is usually a physical location. Any of the content within that Web site, such as subfolders, to which access is gained in a relative manner must reside on that same physical server and shared folder. However, Web sites are usually set up where portions of the site are maintained and administered by different groups.

Dfs works well in this situation. Instead of referencing a physical shared folder as the content location to be managed by IIS, you reference a portion of the logical namespace. The nature of Dfs allows portions of the logical namespace to reside on different servers in the network. So, for example, the \\Company\Intranet namespace might map to the \\Intranet\Root shared folder, the \\Company\Intranet\Sales namespace might map to the \\Sales\Intranet shared folder, and the \\Company\Intranet\Marketing namespace might map to the \\Marketing\Intranet shared folder. Each group in the organization can maintain its own portions of the larger Web site on its own server.

In addition, the logical namespace always remains constant, so it does not matter whether a portion of the Web site content is moved to a different server or shared folder. As long as the Dfs namespace is updated to point to the moved content, nothing on the Web server has to be modified, and the links still work.

Finally, because Dfs can provide high availability and load sharing, a Web farm can be built up in which you have multiple servers that host the same content for a site. As Figure 17.6 shows, if one server fails, another can take its place without the user's knowledge.

Figure   17.6 Intranet Availability