DFS and Clustering

There seems to be some confusion around the Distributed File System (DFS) and Windows Server 2003 server clustering.

First, let’s look at the terms for DFS so we start from the same foundation in this discussion.

  • DFS Root – Think of this as a name space (DFS-N) or share name. This is the name that you connect to as a client computer. Underneath the root are the many different folders and files that may be on a single server or may be distributed around to multiple servers (i.e. some files located in a folder named Accounting on one server and some files located in another folder named Marketing that is on a different server. There are two types of roots. There are domain based roots and there are server based roots. Clustering only supports server based roots. Since a domain based root can be created on multiple servers, it is more highly available. A server root does not have that capability as it can only be created on a single server. With a server based root, if the server is down, then the name space is not available and users can not connect to it.

  • DFS Link – This is a “leaf” type of object that goes under the root. For example, the root (let’s call it CompanyFiles) may be hosted on Server1, but Server2 may have a file share space (call it Accounting) that is linked under the root. Once linked, you can access the accounting share two ways. 1. You can connect to the UNC path of \\server2\accounting or 2. You can connect to the DFS at \\CompanyFiles\Accounting or even browse from \\CompanyFiles and find the leaf object of Accounting underneath it.

  • DFS Replica (also called a target) – This is a folder on the root server or even possibly a link in another DFS tree. What we can do is we can use the source and target information and build replicas (DFS-R) so that certain leaf objects or entire DFS trees can replicate between servers in one location or in different locations.

To be clear, DFS-N (for namespace) is not the same thing as DFS-R (for replication). They are two totally different technologies. One creates the name that can be used by clients to connect to the DFS tree, and the other is used for replication. Server clustering only supports DFS-N and only as a server root. Server clusters can also be leaf objects (but not replicated).

OK, granted this is just some very high level and basic information, but let’s get rolling with it. What does this all have to do with clustering?

Clustering is used to achieve high availability for certain resources. As a business requirement, we may be told to provide solutions that can help us achieve our goals for the company. One of the requirements is to make certain files highly available as they are needed all the time to keep the business running smoothly.

We can achieve our goal (the goal of having highly available file services) a few different ways:

  1. We can use DFS and replicas (DFS-R) to make copies of the file structures that we deem to be extremely important. The problem with using DFS in this manner is that if there is a great deal of change, the replication process may not be efficient enough to keep up. It is not a good idea to use DFS replication in cases where there is constant change. DFS replication works wonderfully where this is little change, i.e. like hosting application source files and drivers. This is not supported in server clusters.

  2. We can use server clustering and create file share resources hosted in our cluster environment. One of the nice options of using file server clusters is that we can use the cluster to host a server based DFS root (DFS-N). Because the root is held in the cluster, it makes it highly available. Also, any data stored on the file share on the cluster is also highly available. The value of using DFS in this implementation is that the name space and the link are highly available and we can connect to many links around the organization to help build an easy to navigate file server structure while only hosting the most important files on the cluster itself.

  3. We can deploy a domain root and use it to link to a server cluster running a file share resource and use it as a leaf in our domain root DFS (this is also DFS-N). The domain root can be made highly available because it can be built on multiple servers, and the most important of our files can be hosted on the server cluster file share.

It is important to note that clusters can not host domain roots. They can only host server roots.

Damn, I hope I got that right. If not, email me.

Exchange Troubleshooting Assistant v1.0

I don’t know how this managed to slip by me.

The Exchange Troubleshooting Assistant, ExTRA, looks like a great tool that can be extremely valuable. I am guessing that, in combination with ExBPA, troubleshooting performance problems or connection issues will become pretty easy for the average Exchange administrator. The tool can be installed directly on an Exchange server or on a client computer that runs .NET Framework v1.1 or higher and is run under the context of an account with proper permissions on the Exchange environment.

I have to admit, I loved that it automatically installed in my Microsoft Exchange menu, so I didn’t have to go hunting for it.

A quick look at this tool showed that it has two starting sections.

  • System Driven

  • Related functionality

The system driven section can be used for troubleshooting based on performance issues and mail flow problems. 

The Related Functions section covers Database Recovery Management. I sure hope it works well, because it has the potential to help an extremely large number of Exchange administrators.

Selecting the Exchange Performance Troubleshooting option leads to a nice drop down that has symptoms of poor performance. I selected one covering delays when using Outlook. I then entered the Exchange server name and the GC name and let it do its work. Since I really didn’t have anything wrong, I only received a few informational messages.

This is a tool that you should download and get comfortable using it. I can imagine a day when you will need it.


DNS Round Robin – IIS

Open up the attachment below. It demonstrates how DNS round robin works.

DNS Round robin is a common solution for enabling load balancing for Internet server farms. Consider the following example in which there are three IP address entries for the same host name on a DNS server. 

In DNS, there are three entries:   WebApp1   WebApp1   WebApp1

You can also replicate this example some time just by playing with your own DNS server. If you create three host records with the same name but with three different IP addresses, you will have implemented DNS round robin as a solution. What happens is that the first client receives the first address, the second client receives the second address, the third client receives the third address, the fourth client receives the first address, and they continue to loop. Using DNS round robin, it is possible to spread the load among multiple servers.

The problem with round robin DNS, is that it is completely unable to handle a down server. In the event one of the servers fail, its address will continue to be given to clients and a portion of the clients will basically be pointed to an invalid address and a portion of the clients will fail to connect.


Round Robin DNS is not a high availability solution.


DNS Round Robin – File or Printer Shares

A common question comes up in the public newsgroups on windows clustering all the time. "Can I use DNS round robin to provide high availability for printers or file shares."

The answer is usually, "No."

The reason is that NetBIOS names are used for these types of connections and the client must know the NetBIOS name of the target server. So, when you try to connect to a UNC path, i.e. \\servername\sharename, this is treated the same as if you were to run the Net command, i.e. "net use * \\servername\sharename" to connect. The * in the command is normally replaced with a specific drive letter and then the drive is mapped. The result is that an attempt is made to resolve the name using normal NetBIOS resolution methods. If those processes fail, then it is possible to use DNS for the resolution if the "Enable DNS for Windows Name Resolution" check box is enabled.

Another reason that you would not want to use DNS round robin for highly available printer or file shares is that DNS resolution of the name to IP address will continue even if the server is not available. For example, if two client computers connect using DNS round robin, one will get the first IP address of the first server, and the second client will get the IP address of the second server, and so on. If the second server goes down, DNS will continue to supply every other client request with the IP address of the server that is down. What you get instead of highly available resources, what you get is halfly available resources. I wonder if I can trademark that term, "halfly available" for this kind of discussion. Of course, the fraction of failures will change depending on the number of servers used.

If your organization needs highly available file resources, you can look at a couple of solutions. First would be DFS with DFS replicas and the second would be server clustering. For highly available printing solutions, server clustering should be your main focus.