Does your organization have virtual files distributed across different locations? Do you need to organize them together into a logical tree? Well, you can do it all with Microsoft’s Distributed File System, or Microsoft DFS, for short. Let’s take a deep dive into this service.
What is Distributed File System?
Microsoft DFS is a mechanism that allows you to create a logical view of folders and files, regardless of where they are physically located on the network. With this service, you have a single point of reference for all the resources within your organization.
Broadly speaking, DFS consists of two components, namely:
- Namespace component for location transparency
- Replication component for redundancy
You can use these components separately or together, it just depends on your requirements.
The namespace allows administrators to group folders located across areas by connecting them to one or more DFS namespaces. In addition, the administrator can decide which shared folders should be present in a namespace, the hierarchical appearance of these folders, and how these shared folders should be displayed in the namespace.
The obvious advantage is easy visibility. When you want to view a shared folder, you simply navigate through the namespace. It simply looks like the folder is sitting on a single hard disk with a ton of capacity. You don’t have to know the complexity behind the folders’ location and their access.
Besides this easy visibility, DFS also comes with fault tolerance and load sharing capabilities, thereby making it essential for every organization.
The replication component replicates your files across different locations for greater redundancy. It does this by using advanced algorithms to reduce bandwidth usage and time.
Before going on to how you can use them, it is important to know how DFS works and the terms associated with it.
Before we go into the working, let’s get familiar with a few terms associated with it.
- DFS namespace — This is a virtual view of shared folders. It consists of a root along with many links and targets. Everything starts with the root, and below that, the links point to different targets.
- DFS link — A component that sits below the root and maps to link targets.
- DFS path — Any path that follows the universal naming convention. This path always starts with the root.
- DFS root — Often the root is referred to the namespace itself because this is the starting point. It can point to other root targets, which are nothing but shared folders on a separate server.
- DFS clients — These are the computers used to access namespaces. They can be end-user computers or computers that run on Windows-based server operating systems.
- Root referral — When a DFS client wants to access shared folders for the first time, a domain controller sends a list of root servers and this is called root referral.
- DFS metadata — DFS metadata contains information pertaining to the namespace and includes information such as roots, links, root targets, link targets, and settings.
- Root servers — Also called root targets, these are the servers where administrators create namespaces. This root server can be a domain controller or just a member server.
- Link targets — These are shared folder or subfolders present inside shared folders. All link targets are accessible through the UNC path, server message block, or NFS for Unix systems.
Now that you understand these terms, let’s get a brief overview of how Microsoft DFS works.
How Microsoft DFS works
The core component of the DFS architecture is Dfssvc.exe, and it runs on both root servers and domain controllers. The main function of this core component is to manage namespace and to communicate with the DFS driver, Dfs.sys.
It is a complex process that involves many other processes and interactions between root servers and clients. Before going further, it is important to understand the different types of namespaces, as DFS works differently for different namespaces.
There are two kinds of namespaces, and they are domain-based DFS namespace and stand-alone DFS namespace.
Domain-based DFS namespace
This namespace has its configuration information stored in Active Directory, so the path to access the root link starts with the domain name. This namespace can have multiple root targets, through which it implements fault tolerance and load sharing.
For example, if the domain name is www.johnsmith.com, your root link will be “\\johnsmith.com\Public”
Stand-alone DFS namespace
In a stand-alone DFS namespace, the configuration information is stored locally in the registry of the root server. To access the root, you have to start with the root server name.
Since the DFS root has only one root server, it is not fault-tolerant. If the DFS root is down, the entire system becomes inaccessible.
For example, the path is “\\ServerName\Sharedfoldername.”
A workaround to this drawback is to create stand-alone DFS namespaces on server clusters.
Now, let’s see how Microsoft DFS works in both these namespaces.
DFS working in stand-alone namespace
Here is a simplified look into how DFS works in stand-alone namespaces.
- When a user tries to access a DFS path, the client sends a query to the root server that hosts the namespace.
- The root server, in turn, sends a root referral to the client.
- The client then sends a query to the root server for the link.
- In response, the root server creates a list of link targets and sends the referral back to the client.
- The client then establishes a connection to the first link in that list.
DFS working in domain-based namespaces
DFS works differently in domain-based namespaces.
- When a user tries to access a DFS path, the client checks its cache for an existing domain name referral. If the domain name is present, the client chooses the first root target in the root referral.
- If the domain name is not present in the cache, it connects to the shared folder of the active domain controller and sends a request with a null string. In return, the domain controller sends the list of local and trusted domains to the client.
- The client sends a query for the requested link. The server sends a list of link targets.
- The client sends a connection request to the first link.
Thus, this is how DFS works for different namespaces.
Next, we’ll move on to the replication component.
Replication in Microsoft DFS
Microsoft DFS replication service replaces the File Replication Service (FRS) introduced in Windows 2000. It is based on a replication algorithm called remote differential compression, or RDC, for short. This algorithm detects additions, deletions, and changes in data arrangement within files, and replicates only those data blocks that are changed.
Here’s a look into some of the features of DFS replication.
- Microsoft DFS is a multimaster replication engine, which means, changes made in one copy is replicated across all members of the replication group.
- It stays on top of the changes made to each file by monitoring the update sequence number and replicates only after you close the file.
- DFS replication uses version vector exchange protocol that sends just 1KB per file to synchronize the metadata of files.
- Updates only the changed blocks in files and not the entire file. This process is handled by RDC.
- In case of conflict, the last writer wins. So, the latest changes alone stay. But the files and folders that fail in conflict resolution are moved to a folder called “conflict and deleted folder.” You can update the settings of this folder at any time.
- It automatically recovers from USN journal loss or loss of the DFS replication database.
These above features show how useful DFS replication is, especially when you have multiple copies spread across different locations.
So, now that we know how DFS and its components work, let’s see how it will help you.
What are the benefits of Microsoft DFS?
Your organization gets enormous benefits from using Microsoft DFS. Here’s a look at some of them.
- DFS makes navigation easy across different shared folders.
- It hides the complexities that come with setting up the virtual namespaces and linking folders together.
- Facilitates administration and takes a lot of burden off the shoulders of administrators.
- Keeps the permissions intact.
- Provides fault tolerance and load sharing, as long as you choose the domain-based namespace. In case you choose the stand-alone namespace, you’ll have to set it up on server clusters to get this benefit.
- Accessing file resources is easy, and no special learning is required.
- The folders can be stored anywhere, and the actual location doesn’t matter at all.
- Changes in one file will be replicated across all members.
- Monitors for changes in files and updates only the changed blocks in files, so bandwidth usage is highly efficient.
- Since DFS is self-healing, your role is greatly reduced.
From the above discussion, it is clear that Microsoft DFS will be a great addition to your organization. Are you ready to leverage its benefits?
Featured image: Shutterstock