|
3.9. The Distributed File SystemThe Distributed File System (Dfs) is a technology that allows several distinct filesystems, potentially on multiple servers, to be mounted from one place and appear in one logical representation. The different shared folders, which likely reside on different drives in different server machines, can all be accessed from one folder, known as the root node. Link nodes serve to point from shared folder to shared folder to mimic a directory tree structure, which can be rearranged and altered according to a particular implementation's needs. Dfs also allows the clients to know only the name of the share point and not the name of the server on which it resides, a big boon when you field help-desk calls asking, "What server is my last budget proposal located on?" Dfs root nodes come in two basic flavors: standalone root nodes, which store the folder topology information locally, and fault-tolerant root nodes, which store the topology structure in Active Directory and thereby replicate that information to other domain controllers. In this case, if you have multiple root nodes, you might have multiple connections to the same datait just so happens that they appear in different shared folders. You even can set up two different share points to the same data on two different physical servers because Dfs is intelligent enough to select the folder set that is geographically closest to the requesting client, saving network traffic and packet travel time. (The redundant share points also replicate around the network, which is another layer of backup protection.) In either case, you can replicate a Dfs root by creating root targets on other servers in the domain. This provides file availability when the host server becomes unavailable. First, let's look at some definitions used in Dfs. A Dfs root can exist either as a standalone entity or as a member of a domain. In either case, the root collects links to all shared paths in the network and publishes those links to users. The childlike links maintain a mapping of a friendly name to a concrete path in a server's filesystem. When a user accesses the Dfs link, the service navigates the mapping and points the user to the destination path. A Dfs target, also known as a replica, refers to either roots or links and serves to combine two identical shares on different servers into one link automatically, with synchronization and replication all a part of it. The major difference between domain-based roots and standalone roots is that of replication. Roots in a domain by default publish their information in Active Directory into the Partition Knowledge Table (PKT). The PKT is distributed to all domain controllers in a domain, which makes it easier for users to connect to shares. In a standalone root environment, only a single server can keep track of the Dfs topology, so if that server is unavailable for any reason, user interruption will occur. You can expand a Dfs topology by adding a link to the root. There's no functional limitation on the number of levels your topology can have, although Windows permits no more than 260 characters in any file path. A new Dfs link can refer to a target with or without subfolders or to an entire disk. If you have adequate permissions, you also can access any local subfolders that exist in or are added to a target. Dfs clients, as mentioned earlier, get referrals to the closest server that houses a copy of the data they request. These referrals are "sticky," meaning they persist until the next system restart. This is done to protect data integrity in environments where replication takes place over great geographic distancesbecause it can take hours or even days before all Dfs changes are replicated to all servers within a domain. If a user had a referral to data stored on a server in Chicago, and then caught a flight home to New York and plugged his laptop back in, the most up-to-date data might not be available to him if changes to Dfs in Chicago had not replicated back to New York at that point. The bottom line is that it's safer for the client to go back from where he came from to get data, at least until system reboot. Windows Server 2003 Standard Edition supports only one Dfs root per server. Other editions, namely the Enterprise and Datacenter editions, support multiple Dfs roots on the same machine. 3.9.1. Adding a Dfs Root and LinkThe following procedure creates a simple Dfs share (which consists of a root node and a child link):
3.9.2. Adding Dfs Links and TargetsYou should not use the steps I outlined earlier for adding a target to add the first target in a Dfs system: that is added when you first create the Dfs link. The folder you specify as the target in step 3 must be an existing shared folder. Additionally, if a link points to another domain's Dfs, it cannot point to any other targets. To add a target in this case, you must add it to the targeted Dfs system, and not to the link itself. To add a Dfs link, follow these steps:
To add a target to a Dfs link, follow these steps:
3.9.3. The Basics of Dfs ReplicationDuring the previous wizard, you might be prompted to configure replication. By clicking Yes, the Configure Replication Wizard is opened. Hold that thought for a moment while we look at how Dfs replication works; then we'll come back to the wizard and step through it. If you have a nondomain-based Dfs system, replication is purely a manual exercise for the administrator, pushing files from a master to slaves in a single-master fashion. One link replica is designated the master. On the other hand, in a domain-based Dfs system, if your data resides in shares on servers running Windows 2000 Server or Server 2003 with NTFS drives, replication is automatic and is multimaster. This means changes are pushed from all servers to all servers, and are orchestrated by an algorithm that takes into account server load, geography, and network link costs. Now, back to the wizard. Bypass the welcome screen and come to the master selection page. Here, you choose a temporary "master" share to start replicationtemporary because, as I just described, all subsequent replications within Server 2003 are a multimaster process, much like domain controllers. Click Next, and the next screen enables you to choose the replication strategies available. You can choose from the following:
Dfs automatically configures the first three for you, so they're simple and likely to work better with Dfs than any other custom topology. You should use the fourth strategy only if you really know what you're doing. Click Finish once you've made your selection, and you will return to the Dfs Management console screen. 3.9.4. Managing Dfs SystemsYou might need to perform a few common administrative tasks on your Dfs structure. This section will describe the procedure for each task. 3.9.4.1 Connecting to different rootsInside the Distributed File System management console, click the Action menu, and then select Show Roots. The Show Root dialog box will open. You can either directly type in the name of the Dfs root or the name of the server that hosts it, or you can browse in the bottom box through a list of the current domain and all domains that trust your current domain to find the server or root. 3.9.4.2 Checking Dfs node statusFrom within the management console, open the root and expand it so that you can see the shares under it. Right-click the share in which you're interested, and select Check Status. The icon in the right pane will change depending on the status; you also can look in the table under the Status field for an update as well. The two possible values are Online and Offline, represented by a green checkmark icon and a red "X" icon, respectively. 3.9.4.3 Removing child nodesIf you have a failed node, you can remove the link from your Dfs system so that clients will not get a faulty referral. This does not remove the actual data or the physical share from the server; it just, in effect, takes the share out of the Dfs table of contents so that users aren't pointed to a broken link. To do so, just right-click the share in the left pane from within the management console and choose Delete Link. 3.9.4.4 Downing replica membersYou can enable and disable Dfs referrals so that users aren't pointed to a server that's unavailable or malfunctioning. This is useful for server maintenance periods, when you don't want users to have their own connections terminated, but you don't want to remove the entire replica set from the Dfs and re-add it when your maintenance window is complete. To disable referrals to a replica, just right-click the share and select Enable/Disable Referral. This action will set the status to whatever is the opposite of the current setting. |
|