Quick Look: What is DFS?
DFS stands for Distributed File System. It's not a particularly new technology (it's been around for several Windows versions now) but it comes with a number of strengths and weaknesses. Before we dive into DFS and what it can do for your environment, let's look at how messy traditional file servers can become.
In my environment, we have 2 file servers. One, let's call it FS1, is our principle file server with many shares on it. The second one, let's call it FS2, sits on slower, cheaper storage and hosts many shares on it with primarily audio, video and other media-type files. FS1 has a screening policy that blocks users from saving media files to it, prompting them to instead save it on FS2. Our users have shares as mapped drives on their workstations. They sometimes have trouble saving the right file-type to the right server. They also have trouble finding the right share sometimes when they need to find a share that isn't one of their mapped drives. Does your organization have something similar?
There's really 2 parts to DFS: Namespaces (DFS-N) and Replication (DFS-R). Each are roles you can install on a server. Let's look deeper into DFS Namespaces.
You can create 2 types of DFS Namespaces: Stand-alone or Domain-based. A stand-alone DFS Namespace is hosted & stored in the registry of the server and doesn't require Active Directory integration. For high-availability you could set it up a Windows fail-over cluster. If a user was to connect to a stand-alone DFS Namespace, they'd simply point File Explorer to \\server\namespace-name much like you would browsing to a share (\\server\share$).
For a domain-based DFS Namespace, you're storing that namespace information in AD and for high availability, you can run multiple DFS servers (EG, multiple servers with the DFS Namespace role) and they'll all subscribe to the same AD (which should be highly available itself since you should have at least 2 domain controllers floating around in your infrastructure). Users can access a domain-based DFS Namespace by simply pointing File Explorer to \\FQDN\namespace-name.
In that namespace, you create folders with targets. For example, if your namespace was "info" and it's a domain-based DFS Namespace, users would browse to \\FQDN\info, you can have folders like "Admin", "Shipping", "Sales" and "Marketing". In those folders can be targets that redirects a user to where the data actually resides. This allows you as an Administrator to organize your data into a logical format based on groups, departments, etc., rather than by what server is hosting that information.
More often than not, an environment might have multiple copies of the files on a file server that they need to keep updated. This is where DFS Replication comes into play. At first, Microsoft used NT File Replication Service (NTFRS) which is a file-level replication solution. Any change to the file and NTFRS would replicate the entire file from the source server to any target file server. This is a very expensive solution from a bandwidth standpoint so it wasn't very efficient. For Server 2003 R2, Microsoft introduced DFS Replication. Like NTFRS, it replicates files between servers but unlike the previous solution, it uses Remote Differential Compression (RDC) to replicate only the changes to a file rather than the entire file itself.
DFS-R and DFS-N aren't necessarily a package deal so you could use one separate from the other if you wanted to. With that said, they do work really well together. From the same management interface, you can create multiple link targets and setup a DFS-R replica. In 2008 R2, you can host a replica on a Windows fail-over cluster. Prior to that, your high availability was simply having multiple copies of the data.
To summarize, you can use DFS-R to publish out data to multiple file servers and use RDC to replicate only the changed bits of a file. You can use DFS-N to abstract multiple file servers from your users by having a namespace with multiple link targets organized in a more logical manner.
In my environment, we have 2 file servers. One, let's call it FS1, is our principle file server with many shares on it. The second one, let's call it FS2, sits on slower, cheaper storage and hosts many shares on it with primarily audio, video and other media-type files. FS1 has a screening policy that blocks users from saving media files to it, prompting them to instead save it on FS2. Our users have shares as mapped drives on their workstations. They sometimes have trouble saving the right file-type to the right server. They also have trouble finding the right share sometimes when they need to find a share that isn't one of their mapped drives. Does your organization have something similar?
There's really 2 parts to DFS: Namespaces (DFS-N) and Replication (DFS-R). Each are roles you can install on a server. Let's look deeper into DFS Namespaces.
You can create 2 types of DFS Namespaces: Stand-alone or Domain-based. A stand-alone DFS Namespace is hosted & stored in the registry of the server and doesn't require Active Directory integration. For high-availability you could set it up a Windows fail-over cluster. If a user was to connect to a stand-alone DFS Namespace, they'd simply point File Explorer to \\server\namespace-name much like you would browsing to a share (\\server\share$).
For a domain-based DFS Namespace, you're storing that namespace information in AD and for high availability, you can run multiple DFS servers (EG, multiple servers with the DFS Namespace role) and they'll all subscribe to the same AD (which should be highly available itself since you should have at least 2 domain controllers floating around in your infrastructure). Users can access a domain-based DFS Namespace by simply pointing File Explorer to \\FQDN\namespace-name.
In that namespace, you create folders with targets. For example, if your namespace was "info" and it's a domain-based DFS Namespace, users would browse to \\FQDN\info, you can have folders like "Admin", "Shipping", "Sales" and "Marketing". In those folders can be targets that redirects a user to where the data actually resides. This allows you as an Administrator to organize your data into a logical format based on groups, departments, etc., rather than by what server is hosting that information.
More often than not, an environment might have multiple copies of the files on a file server that they need to keep updated. This is where DFS Replication comes into play. At first, Microsoft used NT File Replication Service (NTFRS) which is a file-level replication solution. Any change to the file and NTFRS would replicate the entire file from the source server to any target file server. This is a very expensive solution from a bandwidth standpoint so it wasn't very efficient. For Server 2003 R2, Microsoft introduced DFS Replication. Like NTFRS, it replicates files between servers but unlike the previous solution, it uses Remote Differential Compression (RDC) to replicate only the changes to a file rather than the entire file itself.
DFS-R and DFS-N aren't necessarily a package deal so you could use one separate from the other if you wanted to. With that said, they do work really well together. From the same management interface, you can create multiple link targets and setup a DFS-R replica. In 2008 R2, you can host a replica on a Windows fail-over cluster. Prior to that, your high availability was simply having multiple copies of the data.
To summarize, you can use DFS-R to publish out data to multiple file servers and use RDC to replicate only the changed bits of a file. You can use DFS-N to abstract multiple file servers from your users by having a namespace with multiple link targets organized in a more logical manner.
Comments
Post a Comment