Planning a DFS Deployment

Planning for a DFS implementation requires an administrator to understand the different types of Distributed File Systems and the features and limitations of each type. Also, the administrator must understand what tasks can be automated using DFS and what must be configured manually. For instance, DFS can create the file share for a root folder through a DFS Wizard, but it cannot configure file share options such as share permissions, user connection limits, and offline file settings. Also, DFS cannot manage the NTFS permissions set at the root or link target NTFS folder.

When an organization wants automated file replication, domain-based DFS can utilize Windows Server 2003 FRS to replicate shared folders. The administrator does not need to understand all the technical aspects of FRS to configure DFS replication, but he should understand how initial replication will handle existing data in a target folder.

Configuring File Share and NTFS Permissions for DFS Root and Link Targets

DFS is not currently capable of managing or creating share or NTFS permissions for root targets and link targets. This means that to ensure proper folder access, administrators should first configure the appropriate permissions and, if multiple targets exist, manually re-create the permissions on the additional targets. If multiple targets are used and the permissions are not exact, administrators may inadvertently grant users elevated privileges or deny users access completely. To prevent this problem, administrators should create the target file share and configure the share and NTFS permissions manually at the shared folder level before defining the share as a DFS target.

Choosing a DFS Type

As mentioned previously, DFS comes in two flavors: standalone and domain. Both provide a single namespace, but domain DFS provides several additional features that are not available in standalone DFS. The DFS features available in a DFS tree depend on the DFS root type.

Standalone DFS Root

A standalone DFS root provides the characteristic DFS single namespace. The namespace is defined by the server that hosts the root target. Standalone roots can support only a single root target, but an administrator can configure multiple link targets. Multiple link targets must be kept in sync manually because FRS replication is not an option. Standalone roots are normally deployed in environments that do not contain Active Directory domains.

Domain DFS Root

For an administrator to create a domain DFS root, the initial root target must be a member of an Active Directory domain. A domain DFS provides a single namespace that is based on the domain name specified when the root was created. Domain DFS can utilize FRS to replicate data between multiple root or link targets.

Planning for Domain DFS and Replication

When an organization wants to replicate file share data, administrators should create a domain-based DFS root. Within a domain-based DFS tree, replication can be configured between multiple targets on a single root or link. When multiple targets are defined for a root or link, DFS can utilize the FRS to create replication connection objects to automatically synchronize data between each target.

Tip

As a best practice, it's recommended not to replicate domain DFS roots; instead, replicate DFS links between link targets. To provide fault tolerance for the DFS root, simply define additional root targets that can each provide access to the DFS links.

Note

With Windows 2003 R2, DFS now provides the capability to perform automatic namespace fallback. This means that if a DFS server fails, the namespace will automatically redirect the user request to data to the nearest replica of the data. When a server that is closer to the user becomes available, the user will fall back to the copy of the data that is closest to him or her.

Initial Master

When replication is first configured using the DFS console and the Replication Wizard, the administrator can choose which target server will be the initial master. The data contained on the initial master is replicated to the remaining targets. For targets on servers other than the initial master, existing data is moved to a hidden directory, and the current folder is filled with the data contained only in the initial master shared folder. After initial replication is complete, the administrator can restore data moved to the hidden folder back to the working directory, where it can trigger replication outbound to all the other replicas in the replica set. As a best practice, when adding additional targets to a replica set, try to start with empty folders.

Using the File Replication Service

When replication is configured for DFS links, the File Replication Service (FRS) performs the work. Each server configured for replication is called a replica. Each replica has replication connections to one or many targets in the replica set. The replication connections are one way, either inbound or outbound, and are used to send updates of changed files on a target to other replicas, and if the change is accepted, the data is sent.

In a two-server replica set, server1 and server2, let's assume that server1 has an outbound connection to server2 and a separate inbound connection from server2. Each server uses these two connections to send updated data and to receive and process changes and file updates. When a file is changed on server1, the file change is recorded in the NTFS volume journal. FRS on server1 monitors the journal for changes, and when one is detected, a change order is sent to server2, including the updated filename, file ID, and last saved date. The ID of the file is created by FRS before initial replication or when a file is added to a replica share. When the change order is received by server2, it either accepts the change order and requests the changed file, or it denies the change and notifies server1. The changed file is imported into the staging directory when the change order is created. The file is compressed and prepared to send to the outbound partner, and a staging file is created. When the replication schedule next allows replication to occur, the staging file is sent to the staging folder on server2, where it is decompressed and copied into the target folder.

The Staging Folder

The staging folder is the location where an FRS-replicated share stores the data that will be replicated to other replicas with direct FRS connections. When replication is configured using the Configure Replication Wizard in DFS, the system defaults to creating the staging folder on a drive other than the target share drive. Because replication data will travel through this folder, the drive hosting the staging folder must have sufficient free space to accommodate the maximum size of the staging folder and should be able to handle the additional disk load.

The Pre-Install Directory

When replication is initiated, the source server sends a change order to the destination server and creates staging files in the local staging folder. If the destination server accepts the change order, the staging files are copied from the source server staging folder to the hidden folder called Do_NOT_REMOVE_NrFrs_PreInstall_Directory in the target directory.

Determining the Replication Topology

Windows Server 2003 DFS provides a number of built-in replication topologies to choose from when an administrator is configuring replication between DFS links; they're described next. As a general guideline, it may be prudent to configure DFS replication connections and a schedule to follow current Active Directory site replication topology connections or the existing network topology when the organization wants true multi-master replication.

Hub-and-Spoke

A hub-and-spoke topology is somewhat self-descriptive. A single target is designated as the replication hub server, and every other target (spoke target) replicates exclusively with it. The hub target has two replication connections with each spoke target: inbound and outbound. When the hub target is unavailable, all replication updates stop.

Full Mesh

Using a full mesh topology, each target has a connection to every other target in the replica set. This enables replication to continue between available targets when a particular target becomes unavailable. Because each target has a connection to every other target, replication can continue with as few as two targets.

Ring

In a ring topology, each server has only two connections: one inbound from a target and one outbound to a different target. Using this topology, replication can be slow because a replication update must complete on a target before the next target receives the replication data. When a target becomes unavailable, the ring is essentially broken, and replication may never reach other available targets.

Custom

Custom replication allows an administrator to define specific replication connections for each target. This option can be useful if an organization wants a hub-and-spoke topology, but with multiple hub targets, as shown in Figure 30.8.

Replication Latency

Latency is the longest amount of time required for a replication update to reach a destination target. When replication is enabled, a schedule should be defined to manage replication traffic. Using Figure 30.13 as an example, if the replication connection between each target server is 15 minutes, the replication latency is 30 minutes. The longest replication intervalspoke target to spoke target, such as replication from server A to server Cneeds to hop two connections that replicate every 15 minutes, totaling a maximum of 30 minutes for the update to reach server C.