Windows Server Guides

Replication Designs

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 have the "hub" server, and which have the "spoke" servers.

The key to effective WINS design is managing the bandwidth that it uses, and there is no more important contribution towards the performance and availability of WINS than to create a proper replication design. The primary means of accomplishing this is by choosing the correct WINS topology and selecting the proper role for servers acting as replication partners given the available bandwidth.The two recognized choices for WINS topologies are the Hub-and-Spoke model and the Fully Meshed model. In addition, the WINS servers that participate in these topologies can be configured to be push partners, pull partners or push/pull partners. These topologies and concepts are explored next.

Push versus Pull

In order to present consistent location information to clients, the WINS service has an integrated replication mechanism. There are two types of replication, push and pull, and replication is accomplished by configuring WINS servers as replication partners. Microsoft defines a pull partner as a WINS component that requests replication of updated WINS database entries from its push partner, while a push partner is a WINS component that notifies its pull partner when updated WINS database entries are available for replication. A push/pull partner combines both of these functions. Figure 5.8 is a diagram of these replication mechanisms.

When a WINS server is configured as a pull partner, it queries its replication partner to determine if any updates are available at a pre-defined interval. Pull partners should be used if the following conditions exist:

■ You have slow WAN links or a congested LAN.

■ You need to consolidate WINS database updates that consume bandwidth.

■ You want to exercise control over when the WINS database is updated.

When a WINS server is configured as a push partner, the WINS server notifies its replication partner, or partners, that WINS database updates are available. WINS servers that are configured as push partners should be used in the following conditions:

■ The bandwidth consumed by frequent WINS replication updates is not causing congestion.

■ WINS databases need to be constantly updated.

WINS push and pull replication can address availability issues between the local network and remote locations. By adding a WINS server to a remote location, you can increase the availability of the WINS service in the event that a WAN link or router fails.

Hub and Spoke

The Hub-and-Spoke topology is best suited for large, distributed networks. WINS servers in each physical location connect to a central WINS server, or if business requirements dictate, a WINS server cluster. Clustering will increase performance and availability through Windows clustering technology's load balancing and failover capabilities, respectively.This configuration ensures that the WINS database on each server in each location contains the addresses for every host on the network.

Figure 5.8 Hub-and-Spoke Replication Topology

The type of replication partner you choose for each WINS servers depends on the available bandwidth between the central WINS server and the particular location. For locations that are connected by high-speed, high-capacity links, the "spoke" WINS servers can be configured as push/pull partners. For locations that are connected by slower links, a better choice would be to configure the replication partner as a pull partner.

There are several advantages to employing this topology. First and foremost is the topology's ability to scale as the organization grows. WINS servers can be added to any of the spokes with relative ease because there is only one replication partner to configure, the WINS master server. The second advantage is that, once implemented, this design is more easily managed than the Fully Meshed model. There is only one central database that requires care and feeding and there are fewer replication links to manage.

The disadvantage to this model is that there may be some latency in updating all spokes in a large, distributed environment. If replication schedules for some of the spokes are out of synchronization with other spokes, especially spokes that are pull partners, there may be a delay for an update in one spoke to be replicated in the master database and then picked up by another spoke. A second and more troublesome disadvantage to using a WINS master server in the hub is that the hub is a single point of failure for the entire organization. If this topology is chosen, the reliability of the WINS should be fortified by ensuring that there is redundancy for the database. Furthermore, the WINS database at the hub of the organization should also be well maintained to prevent any corruption in WINS data. Corrupted data that is replicated to the spokes or that breaks replication altogether could cause costly interruptions in service.

Fully Meshed

The Fully Meshed topology is best suited for smaller networks that are limited to a single location, or multiple locations that are connected by high-speed, high-capacity links. In the Fully Meshed topology, every WINS server is configured as a replication partner to every other WINS server, as shown in Figure 5.9.

Figure 5.9 Fully Meshed Replication Topology

Push-Pull Push-Pull Partner_Partner

The type of replication partner you choose for each WINS server is less important for this topology than for the Hub-and-Spoke model. Because accommodating many locations and low bandwidth are not prominent factors, WINS servers can be comfortably configured as push/pull partners.

The advantage to employing this design is the speed of replication. Interconnected WINS servers in a high-speed network can be kept up to date in almost real time. Replication intervals can be shortened to ensure that all changes are replicated very soon after they have been committed to the database.

The disadvantage is that this topology can become unmanageable very quickly if the organization grows. Because every WINS server is configured as a replication partner to every other WINS server, the number of relationships will increase exponentially as more servers are added. WINS replication could potentially saturate the network, and any inconsistencies in replication would be difficult to troubleshoot due to the sheer volume of replication partnerships that would need to be investigated.

Tip_

Use push replication only in areas of high bandwidth, such as on a contiguous LAN segment. Use pull replication across low-bandwidth connections, such as WAN links. Pull replication enables the conservation of bandwidth because it allows replications across slow links to be scheduled in times of off-peak use.

0 0