File Replication service is a multithreaded replication engine that replaces the LMRepl service that is used in Microsoft® Windows NT®. Multithreaded means that several processes can run at the same time to handle multiple tasks. This allows FRS to replicate different files between different computers simultaneously.
FRS does not guarantee the order in which files arrive. Files begin replication in sequential order based on when the files are closed, but file size and link speed determine the order of completion. Because FRS replicates only whole files, the entire file is replicated even if you change only a single byte in the file.
FRS expands on the functionality provided by LMRepl with the following enhancements:
Like LMRepl, FRS is automatically installed on Windows 2000 domain controllers and configured to start automatically. For member servers, the service start value is initially set to manual.
Note
There is no administrative console for FRS. SYSVOL replication occurs automatically just like directory replication. Replication of Dfs files and folders is controlled by the Dfs administrative snap-in.
Although Active Directory replication and File Replication service are separate mechanisms, they are conceptually similar. Therefore, it can be useful to read about directory replication when you are learning about FRS. For information about directory replication, see "Active Directory Replication" in this book.
| Key Terms
FRS terms that you need to know before reading further are: Replication. The process of copying data, from one computer to another, that converges to an identical data set over time. Replication enhances availability and file sharing by duplicating shared files. Replica. A member of a replica set that contains a copy of a shared folder or file. Replica set. Two or more copies of a shared folder that participate in replication. Each copy must be located on a different computer. Initial master. First member in a replica set that is the starting point for automatic replication. This means the files and folders in that replica are replicated to other replicas for the first replication cycle. |
Unlike SYSVOL replication, which is implicitly enabled, replication for Dfs replicas must be explicitly enabled by using the Dfs administrative console. Only domain-based Dfs can use FRS; stand-alone Dfs does not support automatic file replication. Remember that FRS is installed only on Windows 2000 servers and that the service starts automatically only on domain controllers. To start FRS on a member server, use Control Panel. Double-click Administrative Tools, double-click Services, and then use the menu options in the Services console.
To enable or disable FRS replication
If replication is being enabled for the first time, the files and folders on the first server enabled (the initial master) become authoritative. This means those files and folders are duplicated to other replicas for the first replication cycle before multimaster replication takes effect.
Replication is not allowed, that is, the shared folder appears as N/A, under the following conditions:
In addition, the following events do not trigger replication:
For a complete description of Dfs, see "Distributed File System" in this book.
FRS provides redundancy for the content of designated NTFS shares between Windows 2000 servers. The servers can be interconnected in any topology such as a ring or a star configuration. With an appropriate topology and sufficient network support, hundreds of computers can replicate the same set of files or folders. Conversely, one computer can be a member of multiple replica sets.
FRS also provides redundancy for SYSVOL and Dfs distribution by way of multiple distribution paths between the replicas in a replica set. If one replica is down, data flows using a different route. Dampening logic prevents a data file from being sent more than once to any particular replica.
Multimaster replication allows any domain controller or member server to propagate changes to replicated files and folders on any other domain controller or member server. There are no primary/secondary or master/slave relationships. When a replicated file is changed and closed, FRS submits that change to other members in the replica set. Those members decide whether to accept or reject the change according to certain criteria.
For example, suppose a replica set is composed of Computer A and Computer B. If File X on Computer A is updated and then closed, FRS notifies Computer B of the change.
An event time is associated with any change to a file. It denotes when the file was closed after being changed or was last replicated. The default event time window is 30 minutes.
The version number is a numerical value FRS uses to track changes occurring to a replicated file. It is assigned by a counting mechanism similar to the update sequence number (USN) used by Active Directory. When a changed file is closed, its version number increments by one.
FRS uses a "last writer wins" algorithm, which means that the last update to a file or folder in a replica set becomes authoritative for replication, regardless of the document version number or file size. It does not merge changes; rather, the most recent version of a particular file overwrites all older versions. This makes FRS well suited to replicate files that are updated infrequently, such as product specifications, software distribution points, and Web content.
Files that contain information that is updated more frequently must accommodate two scenarios: concurrent users and replication latency.
FRS cannot deny file sharing or enforce file locking between two users who are writing to the same file on two different replicas.
FRS uses Active Directory to manage configuration information so you can administer computers containing replicated data offline. This means you can add or remove replicas, change connections between replicas, or modify replication schedules without needing to communicate with the affected computer.
Note
The Dfs administrative console does not support full remote administration; that is, the affected computer must be online.
To provide secure communications, authenticated remote procedure call (RPC) with Kerberos encryption is used over TCP/IP as the protocol between members for replication. NTFS file permissions are also replicated. Files that are locked by their owners are not replicated until they are unlocked.
FRS works only with Windows 2000 because it relies on the NTFS change journal to provide a persistent (that is, logged) record of files that have changed on a member computer. 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 the system shuts down abruptly.
Network Load Balancing clusters distribute client connections over multiple servers, providing scalability and high availability for client requests for TCP/IP-based services and applications.
The heart of Network Load Balancing is the driver Wlbs.sys, which is loaded into each member server, or host, in the cluster. Wlbs.sys includes the statistical mapping algorithm that the cluster hosts collectively use to determine which host handles each incoming request.
Load-balanced applications need to carefully manage state on the server. State that is persistent across multiple requests or that is shared among clients needs to be shared in locations that are transparently accessible from all cluster hosts. Updates to state that is shared among the hosts needs to be synchronized — for example, by using a back-end database server.
Network Load Balancing provides the following:
Load balancing is static (unless the cluster set changes). The port rules that you create for the cluster's hosts specify the division of the incoming client connections.
If a host fails, the cluster detects the failure and redistributes subsequent client requests to hosts that are still viable members of the cluster. Any client connections that were open when the host failed are ended. On retry, the client connection is routed to a viable host. The downtime for client connections is less than 10 seconds.
Network Load Balancing accomplishes scalability by allowing you to add as many as 32 hosts to the cluster. You can add hosts without shutting down the cluster.