|
|
The distributed file system (Dfs) allows several shared file systems to be mounted from one location. The shares may exist on separate machines, but users can reach them through one folder. This folder is called the root node and is accessible from the Dfs root server. Shared folders on other systems are linked to the root node (Figure 9.28).
Users maintain one connection to the root node on their desktop environment and connect to resources throughout the network without having to establish a connection with each server and folder. The Dfs root node contains link nodes that point to these shared folders and mimic the directory's tree structure. The tree structure can be customized according to users' needs.
Dfs centrally manages shared folders and maintains network permissions. Share and NTFS permissions still apply to individual users—creating the root Dfs share does not compromise previously assigned security permissions.
Root nodes can be configured as standalone or fault-tolerant (or domain-based). The standalone server stores the Dfs directory tree structure or topology locally. Thus, if a shared folder is inaccessible or if the Dfs root server is down, users are left with no link to the shared resources. A fault-tolerant root node stores the Dfs topology in the Active Directory, which is replicated to other domain controllers. Thus, redundant root nodes may include multiple connections to the same data residing in different shared folders.
A fault-tolerant link node can point to two or more shared folders on different servers that contain the same files. This serves two purposes:
The network user requesting access from the fault-tolerant link node will receive address information for each redundant folder. The client then picks the folder closest to it, thereby saving network traffic and time.
Redundant shared folders can replicate automatically, providing data redundancy.
NOTE
Version control may be an issue depending on how users access the folders. A user may overwrite changes another user made to a file. In this case, automatic replication should be disabled and handled by a person or configuration management tool. It should be noted that replica folders must reside on NTFS v5 volumes running Windows Server 2003. It should also be noted that client Dfs software is required to access Dfs shares. Windows Server 2003, Windows 2000, Windows NT 4.0, and Windows 98 come preconfigured with such software. Client software must be downloaded and installed on systems running Windows 95. Currently, only Windows Server 2003 and Windows 2000 Dfs clients may access fault-tolerant Dfs root shares using the directory location services. Clients may still access fault-tolerant Dfs roots using the full UNC root path.
The Dfs is created using the Distributed File System snap-in. It primarily involves the creation of two components: the Dfs root and the Dfs child link.
As previously discussed, the Dfs root may be created either as standalone or domain based. It collects in one central place all links to folders throughout the network. A domain-based root can have multiple Dfs links and supports Dfs shares below the root folder. Thus, Dfs subfolder shares may be created in the Dfs root folder and be accessible to Dfs clients. The domain-based Dfs root stores topology information in the Active Directory, but if the server hosting the root Dfs folder is shut down, access to all child links is interrupted. A replica for the domain-based root share may be created on a separate server to support a redundant failover point (Figure 9.29). All child links are duplicated on the root replica and effectively function as an alternative for the original Dfs root. Standalone Dfs roots do not support replicas at either the root level or the child level.
NOTE
Under Windows Server 2003, support is provided for multiple Dfs roots on a single server. Administrators use this feature to host multiple Dfs roots on a single server. This should reduce the administrative and hardware costs of managing multiple namespaces and multiple replicated namespaces. The feature can be configured using the Configure Your Server Wizard.
Dfs links maintain a mapping or a junction point between the root and individual shared folders throughout the network. When the user accesses a link, the link name resolves the destination shared folder path. The link name simply displays the subfolder within the Dfs root folder; the link is responsible for pointing to the folder's physical location using a full UNC path. A standalone Dfs root can support up to 10,000 links and a domain-based Dfs root can support up to 5,000 links (Figure 9.30).
Each link has a name and owns a replica set with at least one corresponding shared physical folder identified by a fully qualified UNC path name. The replica set may be associated with up to 32 shared folders. The folders in the replica set are meant to contain identical information. To accomplish this, they may be maintained manually or automatically using the Folder Replication Service (FRS).
NOTE
Windows .NET provides a number of enhancements for the Folder Replication Service. This feature exposes more functionality including:
Removal of replication filtering
Display of all types of FRS configurations
Ability to change non-SYSVOL types of FRS configurations
Definition of FRS replica set
Topology creation of such elements as full mesh, star, and hub
Schedule on individual connections
NOTE
To host a domain-based Dfs root or fault-tolerant Dfs link replica folder, the host must be running the Distributed File System service for Windows Server 2003 (and be located on an NTFS volume). Windows 2000 Professional does not come with this service preinstalled and therefore cannot be used to host Dfs roots or target folders. Windows NT 4.0 running with Service Pack 3 may host standalone root and target folders.
Dfs maps logical share volumes to physical disk space throughout the network. The main difference between standalone and fault-tolerant, or domain-based, Dfs roots is that domain-based Dfs roots store topology information in the Active Directory in the Partition Knowledge Table (PKT) object, which is distributed to all domain controllers throughout the domain. A standalone Dfs root does not store PKT information in the Active Directory and so relies solely on the Dfs root host to maintain topology information. Additionally, standalone Dfs servers do not support replica sets. A clustering strategy must be implemented to enable fault tolerance with standalone Dfs roots.
Since a domain-based Dfs root automatically publishes information to the Active Directory, a Dfs client running Dfs v5.0 client software (Windows Server 2003) can access a Dfs share in a couple of ways. The first method involves the domain name and the root share name:
\\domain name\fault tolerant root name\link name\path\file name
The second method involves accessing the fault-tolerant root share name:
\\fault tolerant root name\link name\file name
The standalone Dfs share is accessed by Dfs v5.0 in the following UNC form. This form is also used by clients running Dfs 4.x accessing either domain-based roots or standalone Dfs shares.
\\root host server name\root name\link name\path\file name
NOTE
As of the writing of this book, both Dfs v4.x and v5.0 are available for Windows 95, Windows 98, and Windows NT 4.0.
Files in the replicas in Figure 9.30 are referenced from a Windows Server 2003 client system using
\\domain name\Dfs ROOT 1\Dfs LINK 1\subfolder name\file name Dfs ROOT 1\Dfs LINK 1\subfolder name\file name
or
\\HOST A\Dfs ROOT 1\Dfs LINK 1\subfolder name\file name
In addition to the obvious advantages offered by Dfs sharing files, several others need to be highlighted.
Dfs affords naming transparency that allows users to browse and search the network without concern for physical file location. Dfs share names can more accurately reflect logical meaning for data storage and can be limited to the file system naming structure, which is restricted only by a 260-character path name. File search tools available from the Start 
Search menu may be used to search the logical Dfs structure. This more effectively limits extensive document searches to logical volumes rather than entire physical volumes, which are time consuming.
The logical Dfs namespace allows network resource substitutions to be made without users or client system reconfiguration. A logical share can be redirected to another physical location without affecting the logical Dfs path to file resources. Additional disk space can be added in the form of new subdirectories under an existing Dfs share. Shortcuts and drive mappings on the user's desktop no longer need to be reconfigured as physical hardware changes occur.
Internet Information Server runs on the Windows Server 2003 operating system and acknowledges the Dfs logical drive structure. Web page links in HTML documents do not require update when server names change, or when the underlying physical storage is reorganized, if Dfs logical share references are used.
Although load balancing and high availability can be viewed as positive Dfs attributes, there are some basic concerns. First, since the Dfs client arbitrarily selects a Dfs share path, user access should be distributed evenly among fault-tolerant shares. However, if file and application access is not restricted to Read-Only, multiple versions of a file will be created on replica shares. Even though folder replicas distribute permission, folder, and file changes, file-locking attributes are not replicated. Thus, there is nothing to keep two users from opening the same file on separate Dfs link target folders, which can lead to lost data as a result of overwriting.
Pointing all Dfs clients to a primary share and directing them to an alternative share upon failure of the primary share should alleviate most problems. One share will function as the primary resource, relying on the other one for backup. This can be configured using the Active Directory sites container. Put all computers in the same site as the target host for one of the Dfs link folders. When the Dfs client resolves the link target folder UNC location, it will first attempt connection to the resource within its own site. If this server is down, the client will attempt to connect with the remaining target hosts. In this way, the host in the site container will be the first choice, with the backup being accessed only when the first host is down. This will help eliminate file duplication and data overwrites. Obviously, load balancing will no longer occur, but data loss will be kept to a minimum.
Creating a Dfs share involves the following procedure:
Log on with administrative privileges.
Click Start select Programs choose Administrative Tools select Distributed File System.
Select the Action pull-down window select New Root, as shown in Figure 9.31.
The New Root Wizard appears. Click Next (Figure 9.32).
Select Stand-alone root.
Enter the server name on which the Dfs root will reside (Figure 9.33). Click Next.
Enter a name for the new root in the Root name text box (Figure 9.34). Click Next.
Browse for the folder to share and click Next (Figure 9.35).
The new Dfs root settings are displayed. Click Finish. The new Dfs has been created. Its status may be checked from the Dfs console by right-clicking the share and choosing Show Status (Figure 9.36). A green check mark should appear. This can also be used to test child nodes throughout the Dfs structure.
Create a new Dfs link by following this procedure:
Right-click the Dfs Root and select New Link.
In the New Link dialog window, enter a name for the link the Link name text box, which will be seen by users (Figure 9.37). Enter the network path for the folder to be referenced from the Dfs root in the Path to target (shared folder) text box. Click OK.
The Amount of time clients cache this referral option defines the period during which the client may use the referral before needing to contact the Dfs root for renewal. However, the Windows Server 2003 Dfs client software will refresh its cache's Time to Live for the client cache after every successful share access.
The new link should now be visible from the Dfs console (Figure 9.38). The Dfs share has been created and the link connects to a remote machine. It is important to understand that the Dfs root share is now seen as a local folder on the system with the Dfs root. Notice that the link folders are not accessible from the local drive but through My Network Places. Find the system with the root share and you will see the folder named after the "share name" configured earlier.
Deleting a Dfs share is a straightforward process. Log on with administrative privileges. From the Start menu select Programs select Administrative Tools select Distributed File System. First remove the targeted share from the Dfs console. Then delete the shared folder from the local drive.
NOTE
Currently, only standalone Dfs roots can be used on systems running Microsoft Cluster Server. However, a domain-based Dfs root cannot be used with the cluster product.
|
|
|
| Top |