Avocent SPC420 Replication, Promoting spoke servers, To promote a spoke server to be a hub server

Chapter 5: DSView 3 Servers 75

Promoting spoke servers

Promoting a spoke server to be a hub server is usually done only if the current hub server is no longer operational and will not be brought back into service. (For less severe problems with a hub server, the backup and restore operations can be used.)

If a spoke server must be promoted, be sure to run the replication task, if possible (see Replication on page 75) on all other spoke servers, then on the spoke server being promoted, immediately before the promotion. This will prevent loss of data from the other spoke servers.

(After the promotion of a spoke server to a hub, if the server that was originally the hub becomes operational again, it will have to register as a spoke server, since a system can have only one hub server.)

To promote a spoke server to be a hub server:

1.On the spoke server, click the System tab.

2.Click Tools in the side navigation bar.

3.Click Promote to hub server. The Promote Hub Server Wizard will appear.

4.Follow the prompts and heed the cautionary warnings in the wizard. The spoke server on which the wizard is running will become the hub server, and the other spoke servers will be advised of the changed configuration.

Replication

Replication is a task that synchronizes the hub and spoke server databases. By default, replication runs every 12 hours on each spoke server. A spoke server’s first replication occurs automatically when the spoke server is added to the DSView 3 software system. You may change the interval that the replication task runs on each spoke server, or you may initiate an immediate replication.

During replication, the spoke server sends all of its database changes since the last replication to the hub server. The hub server then incorporates those changes and sends all of its database changes since the last replication to the spoke server (excluding the changes that spoke server just sent to the hub server).

If an item is added on a spoke server, and another item with the same name (but perhaps with different configuration parameters) is added on the hub server, then after replication, both items will appear on both the hub and spoke servers, with a tilde (~) and a number added to one of the names. The administrator should handle the issue appropriately - in some cases, the duplicate item may need to be renamed; in others, the duplicate item should be deleted.

When different changes are made to one existing item, two outcomes are possible. For example, assume an item is added and configured on the hub server and is then replicated to the spoke server. Later, an administrator changes something about the item on the spoke server. Another administrator then changes something about the item on the hub server. When the replication task runs, two things may happen.

In a few instances where no conflict occurs, both changes will be incorporated and replicated. For example, if the hub server’s administrator adds username JaneDoe to the existing user-defined user