Lossless failback algorithm/solution for Netcool* OMNIbus ObjectServer failover pairs (18-Jan-2010)

Lossless failback algorithm/solution for Netcool* OMNIbus ObjectServer failover pairs

Background

At the heart of any Netcool*/OMNIbus deployment (single or multi-tiered) is a core pair of "Aggregation layer" ObjectServers: a primary and a backup. They are connected by a bidirectional ObjectServer Gateway whose job is to:
a) synchronise the ObjectServers on Gateway startup (or reconnection) to ensure the two ObjectServers' data sets are the same;
b) propagate any inserts, updates or deletes in either direction to maintain synchronicity between the two (known as the IDUC cycle).
[ Note: IDUC = Inserts, Deletes, Updates, Control ]

Gateway Resynchronisation types
There are two main types of Gateway resynchronisation (for both unidirectional and bidirectional Gateways) as specified by the Gate.Resync.Type property in a Gateway's properties file.

The first resynchronisation type is as follows:
i) "NORMAL"

This is the default resynchronisation type and uses the following algorithm:
- determine which ObjectServer has been up the longest (this will be the "master" for the resynchronisation process and the other will be the "slave");
- delete all data items of the "slave" ObjectServer;
- copy all data items from the "master" ObjectServer over to the "slave" ObjectServer.

The two ObjectServers are now synchronised.

The second resynchronisation type (primarily created for Collection-to-Aggregation ObjectServer Gateways) is:
ii) "UPDATE"
- determine which ObjectServer has been up the longest (this will be the "master" for the resynchronisation process and the other will be the "slave");
- copy all data items from the "master" ObjectServer to the "slave" ObjectServer that don't already exist in the "slave" ObjectServer;
- update all data items in the "slave" ObjectServer that also exist in the "master" ObjectServer with the copy of the data item from the "master" ObjectServer;
- leave alone any data items that exist in the "slave" ObjectServer that don't exist in the "master" ObjectServer.

The "NORMAL" (default) resynchronisation type is standardly used between a primary/backup pair of ObjectServers since it is the only one of the two resynchronisation types that ensures the contents of the two ObjectServers is the same after a resynchronisation - which is a primary requirement for a primary/failover pair.

The "UPDATE" resynchronisation type was created primarily for Gateways that transfer data from one or more ObjectServers to the Aggregation pair. The primary example is a multi-tiered architecture that has multiple Collection layer ObjectServers feeding up into a single Aggregation layer ObjectServer. This resynchronisation type was created for this scenario.
[ Note: see figure 3, page 9, The Tivoli* Advisor - Issue 14 - ftp://ftp.software.ibm.com/software/tivoli/tivoli-advisor/Tivoli-Adivisor-Issue-14.pdf ] Because there may potentially be more than one Collection ObjectServer Gateway feeding into the Aggregation l...