Example: An Organization Designs a Replication Strategy

  • Article

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

An organization uses Group Policy to distribute 10 GB of software to users in four sites. The software changes nightly, and it is important that clients have access to these updates the following day. To make the software files and updates highly available, the organization creates a domain-based DFS namespace for each branch and then uses the Distributed File System snap-in to configure replication. To make the updated software available even if a hub server is offline, the organization uses redundant hub servers that are connected by high-speed LAN links. The organization also uses staggered replication schedules to distribute the load between the hub servers. Figure 2.15 describes the FRS topology.

Figure 2.15   Redundant Hub and Spoke Topology for Software Distribution to Branch Offices

Redundant Hub and Spoke Topology

The organization uses a separate namespace for each branch so that if the local branch server is not available, the clients transparently access one of the hubs instead of another branch server. The organization enables the least-expensive target selection feature of DFS so that the clients always choose the local branch server when it is available.

In this scenario, the organization configures replication as follows:

  • Each branch has its own replica set, and each replica set contains three members: the branch and the two hubs.

  • Replication between the hubs is enabled at all times, so changes at one hub are immediately replicated to the other hub.

  • Inbound connections between the hub servers are medium priority; all other inbound connections are low priority.

  • Odd-numbered branches replicate with Hub1 from 6:00 P.M. until 7:30 P.M. and with Hub2 from 8:00 P.M. until 9:30 P.M.

  • Even-numbered branches replicate with Hub2 from 6:00 P.M. until 7:30 P.M. and with Hub1 from 8:00 P.M. until 9:30 P.M.

As shown in Figure 2.15, all software updates originate at the hub servers and are replicated to the branch servers on a staggered schedule. If replication completes when the branch is connected to its primary hub, no replication takes place when the branch connects to its alternate hub, because the data will have already replicated between the hubs. Similarly, if one of the hub servers fails or is taken offline for maintenance, the branch servers replicate with the remaining hub, and when the offline hub is brought back online, the two hubs replicate immediately to synchronize their data.

Because of the large amount (10 GB) of software files, the organization prestages new branch servers by restoring the software files to the new branch servers while they are located at the staging site. The organization then transports the new branch servers to the branch sites for deployment. By prestaging the software files, the organization does not need to replicate the initial 10 GB of files across the network. For more information about prestaging replica sets, see "Adding a New Member to an Existing Replica Set" later in this chapter.