DFS-What it is

Finding myself needing to explain why having a single namespace server was a bad idea, I decided to devote today’s post to the Distributed File System: what it is, why you want it, and what you should consider when designing it. I have found that a lot of admins have heard of it, and some even have a pretty good idea of what can be done with it, but often deployments are abandoned because of performance issues. Those are almost never problems with the DFS service; they are symptoms of a flawed design. This post should help with that.

What is DFS?

The Distributed File System is a service that presents file shares, frequently spread across multiple servers, as a single, contiguous directory structure. You can browse to the root of this structure, and view all the shares within it as if you are looking at a shared directory tree on a single server. You can map drives, create shortcuts, or just use the UNC pathway to these shares just like they were a typical share on a single server. These shares can be moved from one physical server to another without having to change the clients’ drive mappings, shortcuts, or UNC paths. There can even be multiple copies of some shares, geographically distributed across your WAN, and DFS can refer users to the closest copy.

What are some common uses for DFS?

There are several uses for DFS in your environment. Think about how you could apply these in your environment, with the focus on flexibility and availability.

• Data migration
  Relocate data from one server to another without impacting clients.
• Increased availability/DR
  Using redundant copies of data, enable continued access even when an outage occurs.
• Server consolidation
  Shares are not tied to physical servers, so you can reduce/retire servers as desired without impacting logon scripts, shortcuts, application paths, etc.
• Local Replicas
  By tying together replicas using FRS or DFSR, DFS referrals can connect clients to their closest local copy of data no matter where they are on your network.
  note:DFS does not replicate data! To keep copies in sync, you want to use FRS, DFSR, or some other technology like Robocopy or rsync.

By using DFS, you can reallocate storage space on servers, move high volume shares from one server to another, and add or remove servers from your file systems as required, and never have to worry about how clients are getting to these shares. Drive mappings in logon scripts, persistent mapped drives, shortcuts, etc. can all reference the UNC pathway of the DFS tree, which then refers clients to the physical paths, all in the background and transparent to the user. If you make a physical change, you only have to update your DFS and all the various client-side ways of connecting to that data will continue to work untouched. Should a server (or a datacenter) go down, you can change the pointers in DFS to resolve to alternate data stores and clients will still be able to connect.

What’s the catch?

Well, there’s not so much a catch as there are a few things to understand about how DFS works, and what clients must do in order to use DFS. Keep in mind that DFS is kind of like CNAMEs for shares…it’s an alias; it’s not the real thing. Clients can use this alias, but ultimately they must resolve this alias to real thing ‘of the moment.’ Having resolved it once, they can keep that in memory for a period of time to speed up subsequent access, at the risk of having invalid information if something on the network changes.

• Clients
  DFS supports Windows clients running currently supported versions of Windows. This should not be a significant problem for most of us, but it does leave out non-Windows machines. Mac, Linux, and Unix machines running a Samba client will have to connect to the physical shares.
• Time
  It will take longer for a client to connect to a DFS path than to connect directly to a physical path…whether or not they notice this is up to you. To use DFS, a client must first resolve the namespace, then connect to the namespace server to obtain the referral, and then finally connect to the physical server hosting the share. For domain-based namespaces, that means an LDAP query to a domain controller, and there will likely be at least two DNS queries involved as well unless the client has the necessary information in its resolver cache. When connecting directly to a physical server/share, the client only needs to resolve the ip.addr of the host, and then make a connection.Because of this, you will want to make sure that you have DNS services close to your clients, a DFS namespace server close to your clients, and in the case of domain-based namespaces (see below) a domain controller close to your clients. Redundant services for all three of these are preferable to ensure performance and reduce single points of failure.
• Caching
  Much like a DNS query response, clients will cache referrals. The longer they can cache, the less traffic DFS generates, and the more quickly clients can make subsequent connections to shares…at the expense of perhaps trying to connect to old paths after something has necessitated a move. Short cache values ensure clients quickly get referrals to updated paths, at the cost of more traffic on the wire.
• Dependencies
  Clients must be able to resolve both the DFS root servers, and the physical servers, using DNS (and NetBIOS if FQDNs are not being used.) Clients must identify domain-based DFS root servers using LDAP queries to domain controllers. Clients access DFS root servers using SMB. DFS tools depend upon RPC traffic to connect to root servers. Latency will result in users perceiving poor performance, so make sure that regardless of where the physical data resides, all of the queries that lead up to accessing the data can be handled local to the clients. If you have clients in a location without a DNS server, a Domain Controller, and a root server, but the data they are trying to access is stored on a local file server, you want to just map them to the physical share and call it a day. Sending a DNS query, then an LDAP query, then a DFS query, and the probably another DNS query, over the WAN just to connect to a local fileserver will be painful at best. If the WAN goes down, that local file share may not be accessible if they users only know the DFS path.

Are there different types of DFS?

Yes, there are both different types, and different modes. The older DFS is considered Windows 2000 mode. Windows 2008 introduces some new capabilities, but those are not backwards compatible to 2003/2000 servers. To use the Windows Server 2008 mode, the domain and namespace must meet the following minimum requirements:

• The forest uses the Windows Server 2003 or higher forest functional level.
• The domain uses the Windows Server 2008 domain functional level.
• All namespace servers are running Windows Server 2008.

If your environment supports it, choose the Windows Server 2008 mode when you create new domain-based namespaces. This mode provides additional features and scalability, and also eliminates the possible need to migrate a namespace from the Windows 2000 Server mode. If your environment does not support domain-based namespaces in Windows Server 2008 mode, use the existing Windows 2000 Server mode for the namespace.

When creating a namespace, you must choose one of two namespace types: a stand-alone namespace or a domain-based namespace. In addition, if you choose a domain-based namespace, you must choose a namespace mode: Windows 2000 Server mode or Windows Server 2008 mode.

Choosing a namespace type

• Your organization does not use Active Directory Domain Services (AD DS).
• You want to increase the availability of the namespace by using a failover cluster.
• You need to create a single namespace with more than 5,000 DFS folders in a domain that does not meet the requirements for a domain-based namespace (Windows Server 2008 mode)—as described later in this topic.

Choose a domain-based namespace if any of the following conditions apply to your environment:

• You want to ensure the availability of the namespace by using multiple namespace servers.
• You want to hide the name of the namespace server from users. This makes it easier to replace the namespace server or migrate the namespace to another server.

Choosing a domain-based namespace mode

Comparing namespace types and modes

Additional reading

• DFS Technical Reference
• Deploying DFS Namespaces
• Migrate a Domain-based Namespace to Windows Server 2008 Mode
• DFS Namespace scalability

With the information above, and a little creativity, you should be well on your way towards designing a scalable, robust, and most importantly, useable DFS. Try it out on a smaller scale, mapping IT and/or security shares into it. Once you get the feel for it, start adding other shares and rolling it out to the user base. You’ll should find DFS to be dead useful once you get started.

I usually start a post with a title in mind, but this time I was drawing a blank. Needing to get it done, I started this out with a random playlist in the background.Towards the end of this post, my favourite Mark Knopfler tune came on, and I felt the title was perfect for this post. <♫> The more you know </♫>

Direct link for RSS and email subscribers…http://www.youtube.com/watch?v=vAxzr9BdnkA

How are you connecting users to shares in your environment?

You might also enjoy:

1. NetBIOS Name Resolution is Full of WIN(S)
2. Eight Simple Rules for Name Resolution
3. error 0x80074e46 while installing an ISA 2006 replica
4. Zen and the Art of Naming Conventions-aliases

Tagged as: best practices, windows