Distributed File System
Distributed File System |
|
These are some of the questions that you might ask yourself when you develop the Dfs namespace or namespaces for your organization.
One of the first questions that needs to be addressed is how many Dfs namespaces you want to put into your domain: a single Dfs namespace or multiple Dfs namespaces. The answer depends on a number of possibilities, including who is to use the domain, what you are going to be publishing in the namespace, how deep you want to allow your namespace to extend, and so forth.
If your domain has a broad scope — geographically, organizationally, or functionally — you might want to define multiple Dfs roots. For example, you might have Users, Projects, and Software_installs. On the other hand, if the domain has a narrow scope, you might want to define a single Dfs namespace.
Remember that with Windows 2000–based clients, deep hierarchies are less of an issue because users are able to use the net use command to delve into the hierarchy. However, if you have a large number of Windows 95–based, Windows 98–based, and Windows NT 4.0–based clients that are going to be using the namespace, you might want to limit the depth of the hierarchy that you present to them. Remember that the path length cannot exceed 260 characters.
Must you build larger, more extensive Dfs namespaces out of smaller, more focused Dfs namespaces? You might want to do this is if you want to present specific Dfs roots to some users as the true top of the hierarchy and also present a set of those same Dfs roots to other users as only the Dfs links in a larger hierarchy. By using a hierarchy of Dfs roots, you can scale the namespace as your organization grows and tailor the namespace for distributed management.
Consider the root of the Dfs namespace to be a launching point into the namespace — that is, a placeholder in the namespace. You probably do not want your roots to get too cluttered with files. You might place a single file in the root (a readme file) that describes the contents and purpose of the namespace. If you take this approach, the underlying shared folder that corresponds to the Dfs root is likely to be an empty directory or one with a single file in it.
Use a domain-based Dfs root for new Dfs namespaces that you are creating in a Windows 2000 domain. Stand-alone Dfs roots lack many of the advantages offered by the domain-based Dfs roots and are provided primarily for backward compatibility.
Only Windows NT 4.0–based and Windows 2000–based servers can host Dfs roots for the creation of large hierarchies of Dfs namespaces. All other physical shares can be included only as Dfs links. They cannot host Dfs roots or link to other shared folders. In Windows NT 4.0, these were called leaf nodes and included shares that were published on Windows NT Workstation, Windows 95, Windows 98, Microsoft® Windows® for Workgroups, and all non-Microsoft shares for which client redirectors are available.
It is recommended that you also keep in mind that architectural differences exist between the Windows 95 or Windows 98 file subsystem and Windows NT 4.0 and Windows 2000 file subsystems. These differences do not allow a Windows 95–based or Windows 98–based client to link directly to a non-SMB share. The only way that Windows 95 or Windows 98 can link to a non-SMB share is if that share has an SMB gateway in place (for example, Gateway Service for NetWare). If you have a large number of Windows 95–based or Windows 98–based clients that need access to Dfs links and you do not have the necessary gateway, it is recommended that you restrict your shares to SMB.
Note that shares other than Windows NT 4.0 and Windows 2000 also have the limitation that they cannot participate in file replication.
The underlying file system for shared folders that are published in a Dfs namespace must be NTFS to take advantage of its security features. In addition, if you are going to set up shared folders as replicas for a Dfs link and you are going to take advantage of Windows 2000 FRS, the file system must be NTFS.
It is recommended that you consider replicas for both Dfs roots and Dfs links in the following situations:
It is recommended that you consider publishing only shared folders that are well established and not likely to be retired in the near future. If you have shared folders whose underlying physical name is dynamic in nature, include it in the Dfs namespace only if you can tolerate the added administrative overhead or develop automated scripts to update the Dfs links.
Also consider limiting the total number of links that are published within a Dfs namespace. A practical limit would be about 1,000 links per Dfs root.
The relationship between your shared folders and Dfs links depends on your naming strategy for shared folders and your naming strategy for Dfs links. They might end up mapping one to one, or they might not. Keep in mind that when you specify the shared folder that is mapped to a Dfs link, you can specify either the name of the actual shared folder itself or a directory that includes the shared folder level. For example, if the name of the shared folder is \\Server\Projects, you can create a link in the Dfs namespace that starts at \\Server\Projects\New.
You must be careful not to create loops in the Dfs namespace. Windows 2000 does not automatically check for loops in your namespace.