次の方法で共有

Push partners

  • [アーティクル]

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 8 Beta

Push partners

A push partner is a WINS server that pushes or notifies other WINS servers (those configured to use it as a pull partner) of the need to replicate their database entries at a configured interval. To configure a WINS server to use push replication, you can choose from several WINS console configurable options. For example, you can enable WINS to push notify configured partners when one of the following events occurs:

  • When the WINS server starts.

  • Whenever an IP address change occurs for a name-to-address mapping in the WINS server database.

  • When a value for Number of changes in version ID before replication is specified--either globally for all push partners or individually for specific push partners--WINS can use this value as a threshold for determining how many incremental changes must be made to the database before it starts push replication to its partners.

To configure any of these options for WINS use, you need to configure push parameters, either the default parameters that the server uses for all push partners or the parameters in effect for a specific partner. For more information, see Modify push partner properties.

Additionally, you can manually start push replication to other WINS servers. For more information, see Send a replication trigger to a selected partner or Send a replication trigger to any specified WINS server.

How updates and WINS settings affect push replication

By default, WINS does not perform push replication unless other related settings are also configured on the Push Replication tab in Replication Partners Properties. For example, WINS uses an update count value of 0. This is set using Number of changes in version ID before replication.

Push replication only occurs at configured replication intervals, unless other push replication settings are configured as well, such as:

  • For Start push replication, selected events such as the At service startup or the When address changes check boxes are selected.

  • The Use persistent connections for push replication partners check box is selected, which can affect how the value of Number of changes in version ID before replication is handled by WINS.

Persistent connections are enabled by default, and replication with partners occurs dynamically as records are updated in the local WINS database. A persistent connection alleviates the need for connections to be opened and closed with each update of the WINS database between WINS server replication partners. Replication with partners occurs at a rate specified by the Number of changes in version ID before replication parameter. With this value set to the default of zero, replication takes place as soon as a change occurs. This default can be changed so that replication occurs at longer intervals.

With persistent connections enabled for push replication, the default value of 0 causes the local WINS server to send a push trigger and notify its push partners each time an update occurs. An update is defined as an incremental increase to the highest version ID in the local WINS database for records the server owns. This can occur when a new name record is registered and added locally or if an IP address change occurs for an existing record.

With persistent connections, you can reduce the update frequency for push notifications, by specifying a non-zero value instead. If a value greater than zero is used, WINS only starts push replication when the highest ID for records it owns has increased an equal number of times.

For example, the current highest version ID for an example server, WINS-A, is currently 1C4 (which is 452 in converted decimal notation). WINS-A also has its Number of changes in version ID before replication set to 2 for either all or some of its push partners.

Suppose that the following four distinct sets of database changes are then made to the WINS server database at WINS-A:

  1. HOST-A refreshes its previously registered name record, though it does not change its IP address.

  2. HOST-B registers a name record, creating a new dynamic name-to-address mapping to the database.

  3. HOST-C registers a previously released name record and, in the process, reports an updated change of IP address for this record.

  4. A pull replication occurs at a specified interval with another WINS server.

Once these changes are entered into the database, the newly revised highest version ID for WINS-A is 1C6 (454 decimal). This is because the changes made to WINS server data that were caused by items 2 and 3 (either a client registering a new mapping or updating the IP address used with a previous mapping) each caused the version ID at that server to increment.

For items 1 and 4 in the previous list of changes, the highest version ID at the WINS server does not increase.

After these changes occur, any or all partners of WINS-A that are configured with a Number of changes in version ID before replication of 2 would then be push notified by WINS sending a replication trigger to those servers.

Example: How push with propagation works

The following figure shows an example of the use of push partners in a replicated WINS network of four servers. In this example, two of the servers--WINS-A and WINS-B--are located at regional data center locations.

WINS push with propagation in a push replication

These servers are both central hub servers in a multiple hub-and-spoke enterprise WINS replication design. In order to ensure frequent convergence of names data between the separate regional hubs, both WINS-A and WINS-B maintain a full push/pull relationship with each other.

WINS-C and WINS-D are site or branch-level spoke servers used on the same replicated WINS network. Respectively, they are both configured as push-only partners of WINS-A and WINS-B.

If updates occur at one hub WINS-A, it is unlikely a remote spoke operating as a push-only partner (WINS-D) would receive those updates in a timely or predictable manner. Although replication between the hubs might occur frequently enough to pose no significant issues, setting the update count to an arbitrarily high value at WINS-B might delay convergence at WINS-D until more than one replication cycle has been completed.

To administratively correct this delay, you can initiate a push replication trigger at WINS-A to be sent to WINS-B, which would queue a replication immediately between the hubs. In doing so, if you also chose the Propagate to all partners when manually starting push replication, then WINS-B would propagate the push replication trigger to WINS-D. This would result in an early notification to WINS-D of the need to use a pull replication to WINS-B, obtaining any interim updates from WINS-A.

Note