1.3 Overview
The File Replication Service (FRS) Protocol is a multimaster replication protocol that is used to replicate files and folders across one or more members in an Active Directory domain. It works to keep copies of a file system tree up to date on all members of a replication group, while allowing any member of the group to change the contents at any time. A particular file system tree being replicated, along with the set of machines to which it is replicated, and the topology of connections between those machines used for replication, is known as a replica set.
The topology of a replica set is a directed graph over the machines in the set. Because the graph is directed, data only flows in one direction on any given connection. All machines in a replica set participate as a client on some connections and a server on others. As the machines in a replica set update the contents of the replicated folder, they are responsible for generating change orders that propagate around the FRS topology. This causes the other members of the replica set to be aware of and (absent a conflict) replicate the update.
Each machine in a replication set keeps a volume sequence number (VSN) that is incremented each time it generates a change order. Each member of a replica set keeps track of the highest VSN that it knows about for each member of the replica set; together they are known as a version vector. By sending its version vector to its upstream partners in the replication topology, the upstream partners can efficiently determine what changes need to be sent and what changes are already known, and send only the appropriate set of change orders back to the downstream partner. For more information on version vectors see section 3.1.1.11.
On a given machine, FRS learns about all replica sets that it is part of, along with all its immediate partners, through a set of Active Directory objects. Replication topology is defined by two types of objects: Member objects represent a given participant, and connection objects that connect two endpoint member objects and define the direction of data flow along with the replication schedule.
FRS detects changes made to any file or folder underneath the replica tree root. Details of a given local change are captured in a change order construct. A change order represents an action that took place on the local file system, such as file write, creation, deletion, or rename. In addition, FRS maintains a single ID record for every file or folder underneath the replica tree root in the file system. The ID record provides the information FRS needs to locate the file on the file system. The ID record also stores any extra properties for the resource, such as file attributes.
A new FRS participant goes through a process called initial sync. This process creates the initial content on the new member by requesting all the data from upstream partners. New participants cannot replicate local changes until the initial sync is concluded.
At sync time, which is defined by the connection schedule, FRS establishes a connection with its upstream partner through the remote procedure call (RPC) interface exposed by every running FRS instance (one FRS instance per server). The connection is directed, so changes flow from the upstream partner to the downstream partner. FRS receives the version vector from its downstream partner in a process called Version Vector Join (or VVJoin), during which the upstream partner determines the changes that it needs to send to the downstream partner. For every such change, the upstream partner passes an appropriate change order to the downstream partner. The downstream partner inspects every change order it receives and decides, based on its local changes, to accept or reject the change. Typically, a change order is rejected if the local version supersedes the remote version of the resource. On accepting the change order, the downstream partner fetches the resource via one or more stage packets that carry the data as part of their payload in FrsRpcSendCommPkt method requests. Large files are partitioned into several stage packets that are serialized so that the downstream partner can reconstruct the file after receiving all the pieces.
File contents are marshaled before transfer over the wire to capture file system-specific metadata along with file data in one binary stream. The marshaled representation of a file is known as a staging file. The receiving partner has to be able to unmarshal the file at its end prior to placing it in the target location on the file system. The replicated file can also be compressed when it is marshaled to save bandwidth.
If two or more users are creating files with the same file name on different replica set members, these files will have name collisions with each other as they replicate to other members. Each of these created files is a distinct object with unique content, but only one can be kept. FRS detects that a name collision has occurred when the second file is replicated to a member after a previous file has arrived. FRS then performs the last-writer-wins reconciliation between the two distinct objects. The loser gets deleted, and the delete is propagated out to the other members. The winner keeps the name and gets installed on the member.
For folders, things are a bit different because they can have files and folders underneath them. In this case, FRS again detects the name collision when the second folder is replicated to a member, and it performs last-writer-wins reconciliation; except, in this case, the winner gets a new non-conflicting file name (referred to as a morphed name), and the loser gets to keep the original folder name. The rename is replicated out so all copies of the renamed folder object get the same new name.
FRS supports four types of replica sets:
FRS_RSTYPE_ENTERPRISE_SYSVOL (1)
FRS_RSTYPE_DOMAIN_SYSVOL (2)
FRS_RSTYPE_DFS (3)
FRS_RSTYPE_OTHER (4)
FRS_RSTYPE_ENTERPRISE_SYSVOL and FRS_RSTYPE_DOMAIN_SYSVOL are used for SYSVOL replication.
FRS_RSTYPE_DFS is used for DFS replication. FRS_RSTYPE_OTHER is used only for testing.
The SYSVOL replica set is an FRS Replica set that has all the DCs in the domain as its members. It is created by default when a new domain is created. Every DC that is added to the domain is automatically joined as a member of this replica set. The SYSVOL replica set is mainly responsible for replicating policy data between the domain controllers.
FRS exposes two sets of RPC interfaces:
Communication Interface—Exposes functions to implement the FRS replication protocol.
Programming Interface—Exposes functions to implement administrative and monitoring tasks.
Each file or folder is assigned a GUID when it is first added to a replica set. All replicas in the replica set use the same GUID to refer to the file or folder.<1>