Design Scenario Determining WINS Population

Michelle is trying to determine how many WINS servers she will need for her organization. Currently, she has four sites, each of which will have domain controllers from her domain. The corporate office consists of 15,000 users and each of the regional offices employs between 5,000 and 10,000 users. Four regional offices exist: Washington, DC, with 5,000 users; Los Angeles with 6,500 users; Atlanta with 8,000 users; and Houston with 10,000 users. All of the offices are connected to the corporate office through T1 connections. In order to control the replication of Active Directory objects, sites have been created for each location. She has already decided upon the hardware that she is going to use for the WINS servers: a Pentium 4 2.4GHz processor, 512 MB RAM, and 100 Mbps network cards. A performance test on the hardware has proven that the servers can handle more than 20,000 queries per second in the lab, while the anticipated peak query rate is 13,000 queries per second.

Michelle wants to make sure that each of her locations has a level of redundancy that will guarantee name resolution in case of a link failure between locations or a server failure within the site. She also wants to keep the WINS traffic that has to pass across the WAN links to a minimum.

1. Question: Where should Michelle locate WINS servers to meet her needs? Answer: She should place a WINS server at each location to make sure that she has name resolution capabilities even if the WAN link fails.

2. Question: How many WINS servers are required at each location to support queries? Answer: The hardware specifications will allow one server to support all of the users at the same location as the WINS server; however, you may need to add additional hardware to support redundancy.

3. Question: To support all of the requirements that she has identified, redundancy, and efficient use of the WAN link, how many WINS servers should Michelle implement? Answer: She should implement at least ten WINS servers, two at each location. When she locates the WINS servers at each site, she is reducing the query traffic on the WAN links. By implementing two WINS servers at each site, she will also meet her specification that name resolution will survive if a WINS server fails.

Identifying WINS Replication Options

WINS replication is enabled by choosing which servers will be made replication partners of one another. With the exception of automatic partner replication, the administrator is responsible for determining which servers will replicate with each of the other servers in the organization. Automatic partner replication, if turned on, will find other WINS servers within the same subnet and automatically create replication connections to them. WINS servers in other subnets are not detected and will not participate in the automatic partner replication. The administrator must explicitly configure the replication between two servers. Replication can be configured as push replication, pull replication, or push/pull replication.

Tip If your infrastructure allows multicast forwarding between subnets, the WINS servers will configure automatic partner replication.

Inpushreplication , the replication partner that is the owner of records is configured to wait until a specific number of record changes has occurred before notifying its partners that there are changes they need to accept.

Inpull replication , the replication partner is configured to wait a specific amount of time before requesting a list of the changes from its partners with which it is configured to replicate.

Push/pull replication configures a partner to utilize both options when working with its partners. Whenever possible, you should try to configure your WINS replication partners to use push/pull replication. Using push/pull replication will allow you to maximize the replication topology. If several record changes exist, the push partner will notify the pull partner that it needs to request the changes. During slow times when there are not very many changes to the WINS database, the pull partner will still request the changes, but only after a certain time interval has passed. Having each of the WINS servers configured in this manner will allow you to preserve the WAN traffic while minimizing false responses from the WINS server when a client queries.

You will need to determine the maximum amount of time you will allow before changes should be replicated to each partner. The longer you wait before implementing pull replication or the more changes you allow before you initiate push replication, the more out of sync the WINS servers will be. In order to maintain a consistent WINS topology, you need to take into consideration the convergence time that will occur as the WINS servers replicate all of the changes. The more hops a record needs to take going from WINS server to WINS server, the longer the updates will take to reach every server within the organization. Try to use a hub-and-spoke method of propagating the changes. Figure 10.4 shows an example of the hub-and-spoke method of replicating changes.

All servers configured as push/pull partners m

WINS Server

WINS Server

WINS Server

Was this article helpful?

0 0

Post a comment