Choosing a Replication Method

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

If you plan to use multiple targets and you want to synchronize data in those targets, you need to choose a replication method. You have several methods for replicating data:

  • A manual replication method (such as using the command-line tool Robocopy.exe, which is available in the Windows Server 2003 Deployment Kit)

  • FRS

  • A third-party replication tool

It is not mandatory to use FRS to keep targets synchronized. In fact, by default, FRS is not enabled for DFS targets in domain-based DFS namespaces. However, in general you do want to make sure that the underlying shared folders that correspond to DFS links and targets are synchronized to present the same data to users, regardless of the folder that they want to access.

The following sections describe when to use manual replication or FRS. For an Excel spreadsheet to assist you in documenting the replication method for each target, see "DFS Configuration Worksheet" (Sdcfsv_1.xls) on the Windows Server 2003 Deployment Kit companion CD (or see "DFS Configuration Worksheet" on the Web at https://www.microsoft.com/reskit). For information about using third-party replication tools, consult the documentation provided by your software vendor.

When to Use Manual Replication

If the data in the shared folder is static, you can replicate the data by doing a one-time copy of the data to a target in the replica set. Even if the data in the shared folder is dynamic but changes infrequently, you might want to keep the targets synchronized by downloading the initial copies over the network and then manually updating them with changes. You must use manual replication if you plan to use a stand-alone DFS namespace or if one or more link targets for a particular link do not run Windows 2000 Server or Windows Server 2003.

When to Use FRS

FRS works by detecting changes to file and folders in a replica set and replicating those changes to other file servers in the replica set. When a change occurs, FRS replicates the entire file, not just the changed bytes. You can use FRS only if you are using a domain-based DFS namespace, and only servers running a Windows 2000 Server or Windows Server 2003 operating system can be part of a replica set. In addition, all replica sets must be created on NTFS volumes.

FRS offers a number of advantages over manually copying files, including:

Continuous replication   FRS can provide continuous replication, subject to server and network loads. When a file or folder change occurs, and the file or folder is closed, FRS can begin replicating the changed file or folder to outbound partners (that is, the replica members that will receive the changed file or folder) within five seconds.

Replication scheduling   You can schedule replication to occur at specified times and durations as needed by your organization. Scheduling replication to occur during evening hours, for example, can reduce the cost of transmitting data over expensive WAN links. Replicating data during off-hours also frees up network bandwidth for other uses.

Compression   To save disk space, FRS compresses files in the staging directory by using NTFS compression. Files sent between replica members remain compressed when transmitted over the network.

Authenticated RPC with encryption   To provide secure communications, FRS uses Kerberos authentication protocol for authenticated remote procedure call (RPC) to encrypt the data sent between members of a replica set.

Fault-tolerant replication path   FRS does not rely on broadcast technology, and it can provide fault-tolerant distribution via multiple connection paths between members. If a given replica member is unavailable, the data will flow via a different route. FRS uses logic that prevents a file from being sent more than once to any given member.

Conflict resolution   FRS can resolve file and folder conflicts to make data consistent among the replica members. If two identically named files on different servers are added to the replica set, FRS uses a "last writer wins" algorithm, which means that the most recent update to a file in a replica set becomes the version of the file or folder that replicates to the other members of the replica set. If two identically named folders on different servers are added to the replica tree, FRS identifies the conflict during replication and renames the folder that was most recently created. Both folders are replicated to all servers in the replica set, and administrators can later merge the contents of two folders or take some other measure to reestablish the single folder.

Replication integrity   FRS relies on the update sequence number (USN) journal to log records of files that have changed on a replica member. Files are replicated only after they have been modified and closed. As a result, FRS does not lose track of a changed file even if a replica member shuts down abruptly. After the replica member comes back online, FRS replicates changes that originated from other replica members, as well as replicating local changes that occurred before the shutdown. This replication takes place according to the replication schedule.

When you use FRS, the link targets might not always be completely synchronized. As a result, one client’s view of a link in a DFS namespace can be different from another client’s view of the same link. This inconsistency can happen when clients have been referred to different link targets in the namespace. Link targets do become consistent with time, but you might experience temporary inconsistencies due to replication latency when updates are occurring. For more information about using FRS, see "Choosing an Availability Strategy for Business-Critical Data" later in this chapter.

FRS is typically used to keep link targets synchronized. It is also possible to put files and folders directly in a domain-based DFS root target and then enable replication on the root so that the files and folders are replicated to all root targets. However, avoid enabling replication on domain-based DFS roots for the following reasons:

  • Morphed folders can occur under the DFS root folder. Morphed folders occur when two or more identically named folders on different servers are added to the replica tree. FRS identifies the conflict during replication, and the receiving member protects the original copy of the folder and renames (morphs) the later inbound copy of the folder. The morphed folder names have a suffix of "_NTFRS_xxxxxxxx," where "xxxxxxxx" represents eight random hexadecimal digits.

    Morphed folders occur in replicated roots for the following reason: When you create a link in the namespace, DFS creates a link folder under each root folder on every root server. For example, if you add 1,000 links to a namespace, DFS creates a link folder under the DFS root folder for each of those 1,000 links on every root server. When you enable FRS replication on the root, FRS attempts to replicate its local copy of the folder structure to every root server. Because each root server has a local copy of the same folder structure as the incoming changes, FRS identifies the duplicate folder names and renames the folders that were most recently created. FRS then replicates all morphed folders to all root targets in the replica set.

    Note

  • When adding a new root target to an FRS replicated root, you cannot replicate the contents of individual folders in the root based on business priority. Instead, the entire contents of the root are replicated to the new root target. On the other hand, if you enable replication only on individual links, you are creating multiple replica sets, which allows you to enable replication on the most important links first and then enable replication on the links in the namespace as desired.

  • You cannot take individual root targets offline. For example, if you are adding a new root target, users who are referred to the new member might see incomplete data until replication is complete. On the other hand, if you enable replication on individual links, you can take a new link target offline while the initial replication takes place or whenever you want to restrict access to a particular link target.