Building Your WINS Server Strategy

When building your WINS server strategy, account for any existing hardware that you might need to upgrade, how many WINS servers are needed for your design, and how your server strategy increases WINS availability and optimizes WINS performance. Figure 4.2 shows the process for building your WINS server strategy.

Figure 4.2: Building Your WINS Server Strategy

Reviewing WINS Hardware

Determine whether your current WINS server hardware is sufficient to upgrade to Windows Server 2003. You might need to upgrade your server hardware for optimal WINS performance. A dual-processor WINS server increases performance about 25 percent, and a dedicated disk drive measurably improves WINS server name replication response time.

When selecting your hardware, consider the following performance guidelines:

• Use high-performance disk hardware. WINS causes frequent and intense activity on server hard disks.

• Consider using a redundant array of independent disks (RAID)-based solution, which improves disk access time.

• When evaluating the performance of a server, include WINS to ensure the server can handle its demanding use of central processing unit (CPU), memory, and disk input/output (I/O). Monitor server usage to determine whether WINS server hardware needs to be upgraded.

For a current list of compatible hardware, see the Hardware Compatibility List (HCL) link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

For more information about determining hardware compatibility, see "Planning for Deployment" in Planning, Testing, and Piloting Deployment Projects of this kit.

Determining How Many WINS Servers to Deploy

The number of WINS servers needed and the locations of each server depend on the number of WINS clients per server and the network topology.

The number of users each server can support depends on usage patterns, data storage, and the processing capabilities of the server. A WINS server can typically register 1,500 names per minute or answer 4,500 queries per minute. This means that a single WINS server can adequately service up to 10,000 clients.

You might install additional WINS servers in locations separated by slow, or pay-by-usage wide area network (WAN) links. Set conservative client counts for a WINS server to minimize client query response times. Allow room in your design for peak-load conditions, such as large-scale power outages that force many computers to restart simultaneously, thereby bombarding the WINS servers with registration requests.

Designing WINS for High Availability

Any design that requires high availability must include more than one WINS server. Consider all possible points of failure, including servers, WAN links, and routers. These factors, along with the business goals of the organization, determine the required level of WINS redundancy and fault tolerance.

To ensure that you are planning a fault-tolerant WINS design, ask the following question for each server on your network: What happens to WINS if this server shuts down or if clients cannot reach it?

To help answer the question, consider two common situations in which a WINS server might fail to perform its role on a network:

• A hardware or power failure requires downtime for server repair or maintenance.

• A network link or router failure isolates a WINS server from clients.

To prepare for both of these situations:

• Consider the length of time a WINS server might be out of service on your network, factoring in both planned and unplanned outages.

• Consider what happens to your WINS clients if their primary WINS server shuts down. By maintaining and assigning secondary WINS servers for clients, you can reduce the impact of a single WINS server being offline.

For each client, specify the servers for WINS lookup and the node type. When designing your WINS client support strategy for maximum availability, do the following:

• Specify multiple WINS servers for clients to provide server redundancy.

• For fault tolerance in the case of link failure, point clients to a local WINS server as their primary WINS server, and a remote WINS hub as their secondary WINS server. Ideally, the secondary WINS server is located in a separate building and on a separate power grid from the primary WINS server.

• Consider using an Lmhosts file to provide secondary name resolution in the event of a WINS failure.

  While Lmhosts files are not a recommended solution, in rare circumstances they can provide an effective temporary solution. Lmhosts files must be tightly managed because changes in the NetBIOS environment do not automatically update in static name files.

  For more information about the Lmhosts file, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Using Multiple Servers

To provide additional fault tolerance, configure a secondary (or backup) WINS server. Although WINS replication architecture benefits from employing a minimum number of WINS servers, employing a secondary WINS server improves the availability of your design. This solution balances performance and availability against cost and manageability.

When using two WINS servers to provide redundancy and load balancing, configure the replication relationship between these servers as a pull or push partnership. When you use replication, both servers contain the same WINS database information.

When a WINS server is configured as a pull partner, it periodically queries the partner server to determine if any updates are available. Use pull partnerships:

• Over lower-speed WAN or congested local area network (LAN) connections.

• To reduce replication traffic by consolidating WINS database updates.

• To perform WINS database updates at scheduled intervals.

When a WINS server is configured as a push partner, the WINS server notifies the partner server that updates are available for replication. Use push partnerships:

• Over LAN or higher-speed WAN connections.

• When the network traffic created by frequent WINS replication updates is not a consideration.

• To ensure WINS database updates are received as soon as possible.

The availability that is provided by WINS replication is appropriate for solving availability issues at local and remote locations. Adding a WINS server to a remote location ensures WINS availability in the event that a WAN link or router fails. For more information on replication strategies, see "Designing Your WINS Replication Strategy" later in this chapter.

Using Windows Clustering

Windows Clustering provides a higher level of fault tolerance but consumes additional system resources. If your business goals require a WINS design that provides the highest availability, use server clusters as provided by Windows Clustering. By configuring WINS on multiple servers belonging to the same cluster, you:

• Share a common WINS database.

• Provide immediate failover in the event of failure.

• Restore failed servers sooner, because database resynchronization is not required between the cluster nodes.

Note

If you choose to cluster your WINS servers, be sure to equip the servers with a hard disk containing high-speed I/O that is dedicated to WINS. This can speed up the database response and ensure clustering efficiency.

Example: A Company Uses a Cluster to Simplify their WINS Design

A large corporation uses a server cluster to provide infrastructure services, including WINS. Prior to implementing the server cluster, the company had a large and complicated Windows NT 4.0-based WINS replication topology. To maintain consistency and provide accurate information to clients, WINS client records were replicated to all WINS servers.

To simplify the replication matrix, provide redundancy, and more efficiently manage the WINS traffic load, a server cluster is used as the WINS replication hub. Applications and services running on nodes in the cluster are exposed to users and workstations as virtual servers. Figure 4.3 shows the replication matrix before the WINS cluster implementation.

Figure 4.3: WINS Topology Pre-Clustering

Figure 4.4 shows the new simplified replication matrix using a server cluster.

Figure 4.4: WINS Topology Post-Clustering

Windows Clustering only solves local availability issues. Windows Server 2003-based servers that belong to the same cluster require persistent, high-speed connections between all servers in the cluster.

Note

Before adding WINS to a set of clustered servers, be sure to consider both the advantages and disadvantages of doing so. In many cases, the overall number of WINS servers is small, so clustering WINS is not necessary — replication makes WINS fault tolerant. Instead, configure your WINS clients with the address of a secondary WINS server to ensure uninterrupted service.

For more information about server clusters, see "Designing Server Clusters" in Planning Server Deployments of this kit.

Caution

WINS does not support rolling upgrades from Windows 2000 to Windows Server 2003 in a server cluster. You can upgrade and failover to Windows Server 2003. However, when WINS is brought online on Windows Server 2003, it cannot fail back to the Windows 2000 node.

Optimizing WINS Performance

Although WINS is designed to help reduce broadcast traffic between local subnets, it creates some traffic between servers and clients. This is particularly important if you use WINS on routed TCP/IP networks.

To optimize performance, begin by estimating the amount of network traffic between WINS clients and WINS servers under normal conditions. Estimate and monitor the following:

• NetBIOS names commonly registered by WINS clients.

• WINS registration and renewal caused by daily startup of clients.

• Mobile users and their effect when moving within a routed network.

• The effects of slower links, such as WAN links and their effect on replication performance and convergence.

Reducing Response Time

Reducing the response time of WINS improves performance, with the greatest visibility to users and management. As a result, a design that reduces the response time of WINS is highly successful.

The performance of your WINS design largely depends on other network traffic. For example, a subnet that relies on a WINS server elsewhere on the WAN might experience poor performance during peak hours when network usage is high. Increase the NetBIOS name registration renewal period, which defaults at six days, to reduce client-to-server renewal traffic. This setting must be changed on the WINS server.

Obtain reliable figures on the number of locations and hosts that your WINS design must support. When planning for WINS client traffic on large, routed networks, estimate and monitor the effect of name query, registration, and response traffic routed between subnets. Name requests and responses that occur at the daily startup of computers must pass through the traffic queues on the routers and might cause delays at peak times.

Consolidating Multiple Subnets

When you have multiple subnets in a small remote office, consider consolidating the office to one subnet address.

You can do this using asynchronous transfer mode (ATM) switching or a virtual private network (VPN) configuration. By consolidating to one subnet address, you can configure clients to use local broadcasts to resolve names before attempting to contact a WINS server across the WAN. Changing the client to M-node allows it to broadcast locally for resources before contacting a WINS server for NetBIOS name resolution. This can help to reduce the overall amount of WINS-associated traffic, especially WAN traffic.

Use DHCP scope option 046, WINS/NBT Node Type, to configure your WINS clients as M-node clients. For more information about configuring DHCP options at the DHCP server, see "Assign a scope-based option" in Help and Support Center for Windows Server 2003.

Configuring Burst Handling

Burst handling supports a high volume of WINS client name registration. When a large number of WINS clients simultaneously try to register their NetBIOS names, the WINS server can become saturated. In burst handling mode, the WINS server responds positively to clients that submit a registration request before the WINS server has processed and entered these updates in the WINS server database. The WINS server immediately sends a relatively short, random Time to Live (TTL) lease length to all WINS clients. The short TTL lease length forces WINS clients to reregister after the excessive WINS registration traffic subsides, therefore decreasing the load on the network and varying the delay interval to distribute the load over time.

Using the WINS MMC snap-in, you can configure the level of burst handling for the server, which modifies the size of the burst queue.

• To configure burst handling

  1. In the WINS MMC snap-in, right-click the appropriate WINS server.

  2. Select the Advanced tab from the server name properties dialog box.

  3. In Enable Burst Handling, select Low (300), Medium (500), High (1000), or Custom (50-5000) as the burst queue size.

Load Balancing with Redundant WINS Databases

A WINS implementation design provides higher performance by specifying that multiple WINS servers contain replicas of WINS databases. These redundant servers improve performance by providing load balancing.

Use load balancing with redundant WINS databases when:

• The length of time to perform WINS functions is unacceptably long.

• The connections between the WINS servers support the additional WINS replication traffic.

• The traffic generated by WINS clients accessing a WINS server in another location saturates a WAN link.

• The cost of adding a server is not prohibitive.