Mapping the Replication Architecture to the Physical Network

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

After determining the replication strategy that works best for your organization, map the strategy to your physical network. For example, if you have chosen a hub-and-spoke strategy, indicate on your network topology map which sites will have the "hub" server, and which will have the "spoke" servers. Also indicate whether the replication is push/pull, push-only, or pull-only.

Document the configurations of each WINS server, including the hardware configuration, IP address, replication configuration, and replication partners.

The convergence time for the system is the sum of the two longest convergence times to the hub. For example, in an organization that has five WINS servers (WINS-A through WINS-E), if WINS-B and WINS-D replicate with WINS-A (the hub) every 30 minutes, and WINS-C and WINS-E replicate with the hub every 4 hours, the convergence time is 8 hours.

The following examples show three different types of replication.

Example 1: Deploying WINS Over a Large Number of Branch Offices

In this example, a medium-sized company has two main sites: a New York and a Los Angeles office with 500 computers in each office, connected through high-speed links. The company also has more than 160 small branch offices, including local sales offices. To save on the costs of the links, some branches act as concentrators for a region. Figure 4.8 shows a WINS server placement strategy for an organization with many small branch offices.

Figure 4.8   Deploying WINS Over a Large Number of Branch Offices

In most cases, the branches do not have local WINS servers — there is simply no need for a separate server for each branch. Instead, the company adds regional WINS servers when the costs of registration and query traffic increase above the cost of deploying the additional server. When the link to a regional WINS server fails, local names can still be resolved by the broadcast mechanism.

The regional WINS servers are not required for this configuration to function correctly, but they do provide a cost optimization. The company’s network administrators avoid deploying the regional servers whenever possible because the added servers increase the convergence time. Administrators configure regional WINS servers as replication partners of the WINS servers in the main sites.

Clients in the main site are configured with the IP address of their local WINS server as primary, and the IP address of the WINS server in the other main site as secondary. Clients in the regional branches are configured with the IP address of the regional WINS server as primary, and the address of the closest main site WINS server as secondary. The replication interval is set to 15 minutes between sites; therefore, all computers are reachable within 15 minutes of an address registration or change.

Example 2: Deploying WINS with a Concentrated User Base

Figure 4.9 shows the network configuration of another example company that is very different. The network serves a larger company with three sites, Philadelphia, Seattle, and Houston, each with 5,000 users. The number of users justifies two WINS servers at each site.

Figure 4.9   Deploying WINS Over a Few Large Sites

The clients are configured with a local primary and secondary WINS server. Half of the clients have one local WINS server as primary and the other as secondary. The other half has exactly the opposite configuration. This balances the registration and query load over both WINS servers, and it provides a backup for maintenance purposes and in case of a server failure.

The local WINS servers use a very short replication interval of 10 minutes; therefore, all computers within the same site are reachable within 10 minutes of an address registration or change. The replication interval between the sites can be longer — about 30 minutes — because most users work with resources within their site.

Example 3: A Large Hub-and-Spoke Design

Figure 4.10 shows an extremely large WINS implementation, serving more than 100,000 nodes. In a configuration with so many WINS servers, a common error is to create many push/pull relationships for redundancy. This can lead to a system that, while functional, is overly complex and difficult to understand and troubleshoot.

Figure 4.10   Large-Scale WINS Deployment Using Hub Topology

Four major hubs are located in Seattle, San Francisco, Chicago, and Los Angeles. These hubs serve as secondary WINS servers for their regions while connecting the four geographic locations. All primary WINS servers are configured as push/pull partners with their hubs, and the hubs are configured as push/pull partners with other hubs.

The primary WINS servers replicate with the hubs every 15 minutes, and the hub-to-hub replication interval is 30 minutes. The convergence time of the WINS system is the time it takes for a client registration to be replicated to all WINS servers.

In this case the longest convergence time would be 1.5 hours from a Seattle primary server to a Chicago primary server. The total convergence time can be calculated by adding up the maximum time between:

• Seattle primary to Seattle secondary, 15 minutes

• Seattle secondary to San Francisco secondary, 30 minutes

• San Francisco secondary to Chicago secondary, 30 minutes

• Chicago secondary to Chicago primary, 15 minutes

However, the convergence time might be longer for WINS servers connected across slow links. It is probably not necessary for the servers in Paris or Berlin to replicate every 15 minutes. You might configure them to replicate every two hours or even every 24 hours, depending on the volatility of names in the WINS system.

This network contains low redundancy. If the link between Seattle and Los Angeles is down, replication still occurs through San Francisco. If, for example, the Seattle hub fails, the Seattle area can no longer replicate with the rest of the WINS system. Network connectivity, however, is still functional — all WINS servers contain the entire WINS database, and name resolution functions normally. All that is lost are changes to the WINS system that occurred since the Seattle hub failed. A Seattle user cannot resolve the name of a file server in Chicago that comes online after the Seattle hub fails. When the hub returns to service, all changes to the WINS database are replicated normally.