Distributed File System

Replication Strategy

You must consider using the following two types of replication with Dfs to achieve high availability:

Replication of Dfs knowledge (Dfs roots).
Replication of Dfs content (replica sets).

You also need to keep in mind that site topology influences how replication occurs.

Dfs Roots

All Dfs knowledge (such as that in the PKT) for a domain-based Dfs is maintained in Active Directory. Updates to the Dfs configuration initially take place on the Windows 2000 domain controller hosting the PDC FSMO role. Domain controllers may have a different view of the Dfs configuration until multimaster replication from the PDC makes changes fully replicated between all domain controllers in a domain.

With regard to Dfs, this means that the Dfs namespace might not always be exactly the same on all domain controllers. In fact, it will not be the same when changes are made to the Dfs namespace until those changes replicate to all domain controllers. In addition, because all servers that host a domain-based Dfs root obtain their knowledge from domain controllers, there is also a period of time when the servers do not all have the same view of the Dfs namespace.

Be aware of the amount of data that must be replicated for Dfs knowledge. An entry in the PKT uses approximately 400 bytes per Dfs link. A mid-size Dfs namespace with 100 links would require approximately 40 kilobytes (KB). Any changes to that Dfs namespace causes the entire 40 KB to be replicated to all domain controllers in the domain.

Replica Sets

Multiple copies of a shared folder (or replicas) for a Dfs link can be configured with or without content replication. Even if replication is desired, it is not mandatory to use FRS to keep replicas synchronized with one another. In fact, by default, FRS is not enabled for Dfs replica sets. However, you generally do want to make sure the underlying shared folders for Dfs links are kept synchronized to present the same data to users regardless of the folder to which they want access. Microsoft strongly recommends using FRS for automatic replication of Dfs shared folders.

However, if the information in the shared folder is static, its replication can be handled with a one-time copy of data to a replica. Even if the information in the shared folder is dynamic but changes infrequently, you might want to keep the shared folders synchronized by downloading the initial copies over the network and then manually updating them with changes.

Keep in mind that with FRS, as with Active Directory because it uses multimaster replication, the files in the replica set may not always be completely synchronized. This means that one client's view of a shared folder in a Dfs namespace can be different from another client's view of the same folder. This can happen when the clients have been referred to different replicas (that is, physically different shared folders) for the same point in the logical namespace. Shared folders do become consistent with time, but you will experience temporary inconsistencies when updates are being made.

You might want to adjust the schedule and rules for what gets replicated at what times. For example, if you have little available bandwidth between the servers that host the underlying replicas, you might want to schedule replication for off-hours. With dynamic data, you always have to make the trade-off between the amount of latency that you can tolerate with keeping your replicas synchronized and the amount of bandwidth that is consumed. For more information about scheduling replication, see "File Replication Service" in this book.

Site Topology

The Active Directory Sites and Service topology comes into play in a number of ways with respect to Dfs. It is important to understand how Dfs and any dependent services, such as FRS, use the site topology, so that the enterprise requirements for Dfs are taken into account when the overall network architecture is developed.

Domain controllers, which maintain the PKT and other Dfs namespace information, follow the site topology to replicate with one another.
When a server that hosts a domain-based Dfs root starts up, it contacts a domain controller to obtain the PKT. The site topology is referenced to determine the closest domain controller.
When a Dfs client contacts a server hosting a domain-based Dfs root to locate a replica, it must first contact a domain controller to get a list of servers for the Dfs root. The client then selects one of the servers from the list. The Sites and Service topology is used to contact the closest domain controller and also to find the closest Dfs root server.
When a Dfs client selects the share for a Dfs link, a Dfs root server refers the client to a list of replicas that are mapped to the Dfs link. The list is prioritized to give preference to replicas located in the same site as the client.
When you run the Dfs administrative console and connect to a domain controller, the site topology is referenced to find the closest domain controller.

It is recommended that you consider all of these things when you determine the placement of domain controllers, domain-based Dfs root servers, replicas, and Dfs clients with respect to one another in the Sites and Service topology. The greatest concern, of course, is to place replicas within the same sites as the primary users of their information.