When it comes to configuring file servers, many administrators choose to use a distributed file system (DFS) rather than a traditional standalone share point, because of the redundancy that DFS provides. Although DFS can greatly improve the performance and availability of the data stored on your network, these benefits come at a price. There are several different ways of setting up a DFS, and there are pros and cons of each method. This means that if you are considering implementing DFS for the first time, then you are going to need to do some planning first. In this article series, I will explain what you need to know about the various DFS options so that you can figure out which type of DFS is right for your organization.
A Quick Vocabulary Lesson
Before I get into the actual discussion of the planning process, there are some basic vocabulary terms that I need to go over, just to make sure that we are all on the same page.
|DFS Namespace||A DFS Namespace is just a central namespace through which users can see a unified view of the shared folders that are included in the DFS.|
|DFS Namespace Server||This is simply the server that hosts the DFS Namespace.DFS Namespace Root The DFS root is the top level of the DFS namespace. The namespace root and the DFS namespace use the same name.|
|DFS Folder||A DFS folder is simply a folder that is presented to a client within the DFS namespace, but below the DFS root. A DFS folder can exist on the same server as is hosting the DFS root, but it doesn’t have to. DFS folders commonly represent file system resources located on other servers.|
|DFS Tree||A DFS tree is a reference to the DFS hierarchy. The tree starts with the DFS root, and contains all of the DFS folders that have been defined within the root.|
A Standalone vs. A Domain Based Namespace
Now that I have given you a crash course in some of the more common DFS related terminology, let’s get started with the planning process. The first thing that you are going to have to take into account when planning your DFS architecture is whether you want to use a standalone DFS namespace, or a domain based DFS namespace.
Standalone namespaces tend to have a lot more limitations than domain based namespaces do. For starters, you can only host one standalone namespace per server. The server’s namespace matches the name of the server that hosts the root target.
Like other DFS implementations, standalone namespaces do allow you to use multiple folder targets for fault tolerance purposes. In case you are not familiar with folder targets, the basic idea is that each folder target typically hosts a replica of the data that’s associated with a DFS folder. Using multiple folder targets allows you to achieve a degree of fault tolerance, and offers better performance than if the data were only stored in a single location.
The problem with using multiple folder targets in a standalone namespace is that the targets must be manually synchronized unless all of the servers that are hosting the target folders belong to a common Active Directory domain. Often though, standalone namespaces are used in organizations that do not have an Active Directory in place, because as the name implies, a standalone namespace will work in a standalone environment.
As you would probably expect, domain based namespaces require all servers to be members of an Active Directory domain. These types of environments support automatic synchronization of DFS targets. The namespace root namespace is based on a combination of the server’s NetBIOS name and a root name, and is listed in the DNS.
In a domain environment, a server is capable of hosting multiple DFS roots.
In this article, I have explained that one of the key decisions that you will have to make when planning a DFS architecture is whether to use a standalone namespace, or a domain-based namespace. In Part 2 of this series, I will discuss how you can plan for DFS replication.
Got a question? Post it on our Windows Server 2008 forums!