Windows Internet Name Service
Windows Internet Name Service |
|
Configuring WINS replication correctly is essential to an efficient WINS-capable network. The most important features of a proper WINS configuration are described below.
A WINS server can be configured to automatically accept other WINS servers as its replication partners. When a server uses automatic partner configuration, it finds other WINS servers as they join the network and adds them to its list of replication partners.
Automatic configuration is possible because each WINS server announces its presence on the network through periodic multicast announcements. These announcements are sent as IGMP messages for the multicast group address of 224.0.1.24 (the well-known multicast IP address reserved for use by WINS servers).
When WINS uses automatic replication configuration, it monitors the traffic for these multicast announcements. When it detects a new server, it automatically:
If a remote server is discovered and added as a partner through multicasting, it is removed as a replication partner when WINS is shut down properly. To allow automatic partner information to persist when WINS is restarted, you must use manual partner configuration instead.
To manually configure replication with other WINS servers, configure each partner server using the WINS management console.
Automatic partner configuration is most useful in single-subnet environments. It can also be useful for situations in which the reachable network for WINS multicast traffic is extended by configuring routers between subnets to forward WINS multicast traffic between routed subnets.
Because periodic multicast announcements between WINS servers add traffic to your network, automatic partner configuration is only recommended for use if you have three or fewer installed WINS servers on the reachable network.
WINS replication can be set up between WINS servers in untrusting domains without requiring a valid user account in the untrusting domain. To configure replication, administrators for each WINS server must use the WINS management console to configure their respective server to allow replication with the WINS server in the remote domain.
Selecting the right replication interval requires careful consideration. The WINS server database should be replicated frequently enough that the down time of a single WINS server does not affect the reliability of the mapping information in the database of other WINS servers. However, you do not want the frequency of database replication to interfere with network throughput, which can occur if the replication interval is short.
You also need to consider the topology of your network . If your network has multiple hubs connected by relatively slow WAN links, configure replication between WINS servers on the slow links to occur less frequently than replication between WINS servers on fast links. This reduces traffic across the slow links and reduces contention between replication traffic and client name queries.
Consider an example network in which WINS servers at a central LAN site replicate every 15 minutes, while WINS servers in different WAN hubs replicate every 30 minutes, and WINS servers on different continents replicate just twice each day. Figure 7.22 illustrates this variation in replication frequency.
Figure 7.22 Replication over Enterprise Network Configuration
Configurations of other enterprise networks might involve even more zones, each replicating internally on a constant basis with persistent connections, or replicating in short cycles (every 10–30 minutes) to keep the time to convergence short. The servers connecting any two of these zones might replicate daily or hourly.
When deploying WINS servers, you must choose an acceptable convergence time for your network. Figure 7.23 illustrates a network with WINS servers and the database replication interval between them. This sample network configuration shows how the replication interval between WINS servers affects the convergence time.
Figure 7.23 Replication Intervals in a Routed TCP/IP Network
If a WINS client registers its name with the WINS server WINS-C, other WINS clients can query WINS-C for this name and get the name–to–IP address mapping. WINS clients that query any of the other WINS servers do not get a positive response until the entry is replicated from WINS-C to WINS servers to WINS-A, WINS-B, and WINS-D.
WINS-C is configured to start replication when the update count exceeds the push threshold or when the pull replication interval expires on its WINS pull partner, WINS-A. The update count is the number of changes to database entries required to trigger push replication. (In this example, WINS-A is configured with a pull replication interval of 15 minutes, rather than an update count threshold.)
In this example, the entry is replicated only when the pull replication interval expires, but queries for the new name to WINS servers WINS-B and WINS-D might still fail. The interval for replication to WINS-B is 15 minutes; to WINS-D, it is 12 hours. Calculate the convergence time as follows:
12 hours + ( 2 × 15 minutes ) = 12.5 hours
However, name query requests sometimes succeed before the convergence time has passed. For example, this happens when the entries are replicated over a shorter path than the worst-case path. It also happens when an update count threshold is passed before the replication interval expires; this results in earlier replication of the new entry. The longer the replication path, the longer the convergence time.
The WINS server database inherently provides fault-tolerant service because it is replicated among multiple WINS servers in a LAN or WAN. This replicated database design prevents users from registering duplicate NetBIOS computer names on the network. In general, even small networks should have more than one WINS server to distribute the load of processing NetBIOS name queries and registration, and to provide WINS database redundancy, backup, and disaster recovery.
WINS server failures come in two basic types:
The failure of an individual WINS server within a network affects multiple WINS servers. An example routed network, shown in Figure 7.23, contains four separate physical segments separated by routers and four WINS servers. Each segment has a single WINS server to provide primary service to local clients on its own segment. Three of the servers (WINS-A, WINS-B, and WINS-C) are linked by routers contained within a single high-speed LAN link topology. The fourth server, WINS-D, is located on a remote segment that uses a low-speed WAN link.
In this example, a failure of WINS-A or WINS-B would segment the distribution of NetBIOS names. Entries would no longer be replicated from WINS-C to WINS-D, and vice versa. Because the IP address and name would no longer match for updated clients, other clients would not be able to connect to the updated computers. Adding replication between WINS-B and WINS-C would improve the configuration for cases in which WINS-A fails. Adding replication between WINS-D and WINS-C would improve fault tolerance in a case where the WINS-B server fails.
Failures of a single link between A, B, and C would not disable the WINS configuration because the underlying router network would reroute the traffic. Although this is not very efficient compared with a fully operational network, WINS replication does continue relatively undisturbed. Failure of the link between WINS-B and WINS-D, however, segments the WINS configuration. Because this makes other network traffic impossible, the network needs an on-demand backup link between WINS-D and WINS-C. This link would allow the underlying router infrastructure to reroute the WINS replication traffic.
In Figure 7.23, the routers are all single points of failure. When one of them fails, it segments the WINS configuration.
When a link or router between two subnets fails, replication between two WINS servers may well be interrupted or prevented by the link failure. However, a segmented WINS configuration can provide many of the services of a fully functional system. Clients can usually resolve addresses from names. Local WINS servers and/or broadcasts resolve most name queries. The only names that cannot be resolved are new entries that were registered remotely, or those that have been updated since the network was segmented. Entries are not dropped at scavenging time when the owning WINS server cannot be reached. To restore the segmented network to full function, install WINS service on another computer when the hardware of the regular WINS server fails, and restore the database by forcing replication from a replication partner.
Windows 2000 and Windows 98 provide an extra measure of fault tolerance by allowing a client to specify more than two WINS servers (up to a maximum of 12) per interface through either the DHCP or the WINS option under Administrative Tools. The additional WINS servers resolve names only if the primary and secondary WINS servers fail to respond. If one of the additional WINS servers answers a query, the client caches the address of the WINS server that responded and uses it the next time the primary and secondary WINS servers fail to resolve the name. This feature is enabled by default in NetBT. However, if this feature is activated for too many computers, the result is excessive duplication of name queries, resulting in performance degradation.
To plan for fault tolerance, determine the maximum period you ever expect any given WINS server to be out of service. Remember to factor into your assessment the length of both planned and unplanned outages. Also, consider the effect on your WINS clients when their primary WINS server is shut down. By maintaining and assigning secondary WINS servers for clients, the effects of a single WINS server being offline can often be reduced, if not fully eliminated. In addition, clustering can provide further fault tolerance. For more information, see "WINS Clustering" in this chapter.
Finely tuning your replication intervals might conserve some bandwidth on WAN links. Improving the example network in Figure 7.23 results in a network like that shown in Figure 7.24. This new configuration is not only more fault tolerant, but it also has a shorter convergence time. In Figure 7.23, the longest path was from WINS-C over WINS-A and WINS-B to WINS-D. Now the longest path is from WINS-A or WINS-C over WINS-B to WINS-D, with a convergence time of 12 hours and 15 minutes.
Figure 7.24 An Improved Replication Configuration
By keeping the pull replication intervals between WINS-C and WINS-B short (15 minutes), WINS servers WINS-A, WINS-B, and WINS-C are always reasonably well synchronized. Replicas are never pulled more than once, and only replicas with higher version IDs are copied. When WINS-B pulls an entry directly from WINS-C, it does not pull that replica again from WINS-A.
WINS-D and WINS-B might pull replicas from WINS-C over the link between WINS-B and WINS-C, if WINS-B pulls the replicas from WINS-C, and WINS-D then pulls replicas from WINS-C. This increases the load on the link between WINS-B and WINS-C. To avoid this problem, configure WINS-D to pull from WINS-B first and then check WINS-C. The pull replication interval between servers WINS-D and WINS-C remains 12 hours.
To ensure that the replication is triggered by the pull replication interval and not the update count threshold, you must configure push update counts on WINS servers WINS-D and WINS-C that are high enough to exceed the 12 hours pull replication interval. If these counts are too low, the update count threshold triggers unexpected replication.
Choosing whether to configure another WINS server as a push partner or pull partner depends on several considerations, including the specific configuration of servers at your site, whether the partner is across a wide area network (WAN), and how important it is to distribute changes throughout the network immediately.
In the hub-and-spoke configuration, you can configure one WINS server as the central server and all other WINS servers as both push partners and pull partners of this central server. Such a configuration ensures that the WINS database on each server contains addresses for every node on the WAN.
Figure 7.25 Replication using a Central WINS Server
You can select other configurations for replication partner configurations to meet the particular needs of your site. For example, in Figure 7.26, Server1 has only Server2 as a partner, but Server2 has three partners. So Server1 gets all the replicated information from Server2, but Server2 gets information from Server1, Server3, and Server4.
Figure 7.26 Replication in a T Network Configuration
If, for example, Server2 needs to perform pull replications with Server3, make sure it is a push partner of Server3. If Server2 needs to push replications to Server3, it should be a pull partner of Server3.
