Specifications

Chapter 3 Installation and Setup
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 group Accounting and the spoke server’s
administrator adds username JohnDoe to the Accounting user group, both names will be added and replicated.
In most other instances where the changes are mutually exclusive or some other conflict occurs, the most recent change
will be the only change accepted and replicated. For example, if the hub server’s administrator associates a unit with the
Miami site, and the spoke server’s administrator associates the same unit with the Chicago site, the change that was
made closest to the time of replication (that is, the most recent change) will be accepted and replicated.
This emphasizes the importance of ensuring the hub and spoke servers’ clocks are synchronized.
The exception to the last-change rule is when one of the actions deletes an item - in that case, the deletion is accepted
and replicated, regardless of timing. For example, if a unit was deleted on the hub server, and then the contact information
for the same unit was changed on the spoke server a minute later, the unit will be deleted when the replication task is run.
On a spoke server, you may enable a replication task property that forces the spoke server to retrieve a snapshot of the
hub database rather than synchronizing changes back and forth. The snapshot is a copy of the hub at the time of the
operation. This feature is not normally used; it is intended to help recover a system when replication has failed.
3.6.1 Initial load
NOTE: The DTX Control appliance is configured as hub by default.
When a DTX Control appliance is registered as spoke server into another DTX Control appliance, all the data in the spoke
is deleted and overwritten with the data from the hub. This process is called initial load. Once the initial load is completed,
both DTX Control appliances have the same information.
3.6.2 Incremental updates
The incremental updates are done by the pull and push tasks which are executed every period of time (by default 1
minute) by each spoke. The push task takes care of sending all the changes to the hub, while the pull task retrieves
changes from the hub.
If communication between the hub and a spoke is broken, changes are queued in both sides. Upon communication being
reestablished, the push and pull tasks send and retrieve all the changes since the last time the replication was
successful.
To register a DTX Control appliance as a spoke server:
NOTE: Because the spoke database gets deleted in this operation, BLACK BOX recommends making a backup copy of the spoke database first.
1. Click on System - DTX Control - Tools.
2. Click Register as Spoke Server wizard.
3. Click Next.
4. Type the hub's IP address and port (default is 443) and click Next.
5. On the Accept Hub Server Certificate Page, click Next to accept the hub certificate.
6. Enter the hub administrator username and password and click Next.
724-746-5500 | blackbox.com Page 24