When a server runs out of hard disk space, the headaches it can cause could triple the stock value of an aspirin company. The obvious solution is to add another hard drive or maybe even a RAID array, but even RAID arrays have their limitations. Plus, many smaller companies simply don’t have a budget that allows a pricey fix like RAID arrays.
So if your server runs out of hard disk space, and there’s no way to add more storage space to the server, what do you do? One popular solution is to create a Distributed File System (DFS) tree. Although you still have some limitations to deal with, a DFS tree can provide you with almost unlimited storage capabilities. In this article, I’ll discuss why DFS trees are such a good solution. I’ll then go on to show you how to create a DFS tree on your Windows NT server.
What's a DFS tree?
If you’ve never heard of a DFS tree, then you may be wondering how it can increase the storage space of a server that’s already full. The trick is that a DFS tree uses disk space on multiple servers and provides users with the illusion that they are looking at a single server.
If you still don’t get why DFS is such a great solution, then consider the alternative. If a server is filled to capacity with no room for expansion, then the administrator typically has no choice but to move some of the server’s files to a new server. This means that some of the files will have changed locations, and it’s up to you to make the users aware of the new locations. This could mean changing the drive mappings for countless users. Your help desk could also be flooded with calls from confused users whose files are “gone.” Still other users will be upset because half of their files are in one place and half of their files are in another place.
A DFS tree makes this problem disappear. Even though the user’s files may be scattered all over the place, the DFS will make it appear that all of the user's files are in a single location, accessible through a single drive letter.
The DFS allows you to create a virtual directory with unlimited disk space. Anytime you run out of hard disk space, you can simply add another server to the DFS tree. As if this weren’t amazing enough, these distributed servers don’t even have to all run Windows NT. Windows 2000, as well as most UNIX operating systems, natively host DFS. If you’re running the appropriate support services, you can even include NetWare volumes and removable media in the DFS tree.
The DFS Service requires at least one Windows NT Server. This server hosts the DFS tree and controls access permissions. Figure A shows an example of a DFS tree made up of these various sources. Of course, in real life, your directory names probably wouldn’t reflect the type of operating system hosting the share. Instead, your directory would look exactly like any other, giving no clues that its subdirectories are scattered around on numerous computers.
|The DFS can include shares located on several different operating systems.|
All good things come at a price, especially if you still support Windows 95 workstations. That’s because Windows 95 can’t access the DFS tree without a special client. You can download the client from the same Web site where you obtain DFS for your NT server. If you don’t install the DFS client, your Windows 95 workstations won’t be able to access files stored in the DFS tree. If Windows 95 clients attempt to access a DFS tree without the necessary driver, the root share point will appear to be empty.
None of this should be a problem if you’ve already moved on to other operating systems. Windows NT Workstation clients can natively access a DFS tree as long as they are running Service Pack 3 or higher. Windows 98, 2000, Me, and XP can all also natively access the DFS tree.
Another downside is that a single file can’t span multiple servers. For example, in a large organization, the Microsoft Exchange database files can become very large. Because each of these databases consists of a single file, you couldn’t use a DFS to make more disk space available for this file to grow beyond the physical limits of its home server.
The reason for this is that the DFS service makes remote volumes available by making their share appear to be a subdirectory of a master share. Therefore, files on each volume appear to be contained within a separate subdirectory. Needless to say, a file can’t span servers because part of it would have to be in one subdirectory while the rest of the file was in a different subdirectory.
Planning your DFS tree
Before you build your DFS, it’s important to do some serious planning. If you don’t carefully plan the structure of your DFS, you could end up with a file system tree that’s very confusing.
The first step in the planning process is to select a volume on your server that has plenty of free disk space. When you continue setting up your DFS tree, you’ll create a share point on this volume. This share will become the root directory for the DFS tree. Any other volumes you include in the DFS tree will appear as subdirectories off of this root directory.
Once you’ve figured out where to place your root share, you need to do some more planning. Remember that the entire point of a DFS tree is that you can make share points from another server appear to be subdirectories of the DFS root directory. This means that you need to plan your share names very carefully so as not to accidentally create a situation in which two share points have the same name.
It’s also important to consider disk space. Remember that the only way to add disk space to the root share once you’ve created it is to have the root share existing on a RAID array and physically add a hard disk to the array. Linking a share point to the DFS tree does increase the overall size of the DFS tree, but the newly linked server’s disk space is accessible only through the share point. Therefore, a client could potentially be in the DFS root directory and see that there are 2 GB of free space, switch to a subdirectory (which is actually a share point on another computer), and all of a sudden see that there are now 15 GB free. However, that 15 GB would only be available in that subdirectory.
Installing the DFS service
Microsoft released Windows NT version 4.0 before the DFS service was finished. Because of this, most copies don’t contain this DFS. Many of the copies that do contain the service actually contain a nonfunctional copy. Therefore, you’ll have to download the service from Microsoft before you can use it. You can acquire the service at Microsoft’s Windows NT Download Web site.
You can choose between a version of DFS for Intel or Alpha platforms. Chances are that you’ll need the Intel version. Download dfs_v41_i386.exe to a temporary directory on your server. It’s only 441 KB, so it won’t take much time to download. Execute the file to copy and expand it. When you do, the file will automatically copy the files it contains into their appropriate directories.
When the decompression process completes, double-click the Network icon on the Control panel. When you see the Network Properties sheet, select the Services tab and click the Add button. At this point, select Distributed File System from the Select Network Services dialog box and click OK. If the Distributed File System option doesn’t exist, then click the Have Disk button. When Windows NT asks you for the path that you’ll be installing from, specify C:\WINNT\SYSTEM32\DFS. When you see the Select OEM Option dialog box, select the Distributed File System option and click OK.
At this point, you’ll see the Configure DFS dialog box. As I said earlier, only one Windows NT server is required for hosting a DFS tree. Since you’ll be using this server as a DFS host, select the Host A DFS Share check box. Next, select the share that you wish to use for the root directory of the DFS tree, as shown in Figure B. If you don’t have a suitable share, you can click the Create Share button to create a share. Click OK to continue. Now, click Close to close the Network properties sheet. When you do, your Windows NT Server will ask you to reboot the server.
|The Configure DFS dialog box allows you to establish the root directory of your DFS.|
Adding shares to the DFS
Up to this point, you’ve created a root directory but no subdirectories. Creating subdirectories from shares on other computers requires you to use the DFS Administrator program. To start the DFS Administrator, click Start | Programs | Administrative Tools (Common) | DFS Administrator. You can see an example of the DFS Administrator program in Figure C.
|You can use the DFS Administrator program to add shares to the DFS tree.|
As you can see in Figure C, the share you selected earlier appears as the DFS root volume by default. At this point, you can add another share to the DFS by selecting the Add To DFS command from the DFS menu. When you choose this command, you’ll see the Add To DFS dialog box.
Begin by typing the name you’d like to assign to the subdirectory within the DFS tree. Next, type the path to the share you’d like to assign to the subdirectory. Finally, you can type an optional comment to help you remember why this entry is part of your tree. For example, in Figure D, you can see that I included the share \\SCOOBY\MSPCLNT in my DFS tree.
|The Add To DFS dialog box allows you to associate share points from other servers with the DFS tree.|
Since this share name is somewhat cryptic, I named the subdirectory Proxy Client instead of MSPCLNT and included a comment that this directory contains the Microsoft Proxy Server Client. As you can see in Figure E, the DFS makes the Proxy Client directory that I created appear to be just another directory located on the server.
If you ever decide to remove a share from the DFS tree, simply select it from the DFS Administrator’s list of shared directories and press [Delete]. Removing a share from the DFS tree makes it inaccessible through the tree, but the actual data still exists, and you can still access the share through its original share-point name. For example, if I were to delete the Proxy Client virtual directory from the DFS Administrator, I could still access the share through \\SCOOBY\MSPCLNT.
Using DFS to add fault tolerance to Windows NT
When Microsoft updated DFS in Windows 2000, it increased performance and added fault tolerance. Although the Windows NT version of DFS wasn’t really designed with fault tolerance in mind, there is a way to boost fault tolerance in a roundabout sort of way.
Suppose for a moment that you have a file server that contains a heavily used share that acts as a part of the DFS tree. What happens when you have to take the server offline for extended maintenance, but your users don’t have time to wait for the maintenance to be completed? In a DFS environment, you can configure the server to replicate its data to a spare server.
When you have to take the original server offline, you could just ask your users to log off for a few moments. During this time, you’d remove the server’s share point from the DFS tree and then create a new share point. The new share point should link to the spare server but have the same name as the original share point. When your users get back online, it will appear that nothing has happened, even though the users are working off of a different server.
When you complete your maintenance, bring the server back online and let any new data replicate back to the original server. Point the DFS tree back to the new server—and your users are back in business in the original location. The point is that you can have the server down for as long as it needs to be without impacting the user’s productivity.
The Windows 2000 version of DFS allows you to accomplish these tasks without ever forcing the users offline. You can even distribute the user’s workload among multiple DFS servers with identical copies of the user’s data.
The bottom line is that organizing your files using the DFS can help you better organize file directory layouts. DFS can also prevent your servers from running out of hard disk space. To get it working on an older operating system like Windows NT takes a little bit of effort, but in the long run, it can save you time and money.