IBM Tivoli Netcool/OMNIbus, Version 7.4

Configuring high availability

When Tivoli Netcool/OMNIbus is configured for high availability, event loss is minimized, data integrity is improved, and performance is increased.

The multitiered architecture provides the backdrop for a high availability setup in which ObjectServers are deployed in a one-, two-, or three-tiered configuration. The multitiered architecture enables you to start your deployment in the aggregation layer or tier, and to add ObjectServer resources to the collection and display layers, as suitable for your requirements. The one-, two-, or three-tiered configuration is a prerequisite for configuring high availability; at a minimum, your system must be configured for failover and failback in the aggregation layer.

Your Tivoli Netcool/OMNIbus installation includes a set of customizations, which you can apply to your ObjectServers and ObjectServer Gateways to configure each layer. These customizations are provided in the $NCHOME/omnibus/extensions/multitier and $NCHOME/omnibus/extensions/control_shutdown directories.

The following configuration scenarios apply for high availability:

Failover configuration
The failover configuration is a requirement for high availability, and is based around the aggregation layer of the standard multitiered architecture. In its simplest configuration, the failover configuration consists of a primary and a backup ObjectServer that are connected by a bidirectional ObjectServer Gateway in the aggregation layer, with no collection or display layers connected.
Configuring controlled failback of clients
To minimize event loss, which can occur if clients fail back to a primary ObjectServer before resynchronization is completed, client failback behavior must be controlled by a failover pair of ObjectServers instead of the clients themselves. The configuration for controlled failback is based around the aggregation layer in the multitiered architecture.
Configuring probes for high availability
For the probes in your environment, you can configure high availability by setting the probes to run in circular store-and-forward mode. Alternatively, if the probe has peer-to-peer failover functionality, run two instances of the probe in a master-slave configuration.
Reducing event loss on ObjectServer failure during resynchronization
To minimize event loss when an ObjectServer fails during resychronization, an ObjectServer property ActingPrimary is used to define which ObjectServer was acting as the primary if the last resynchronization was not successful. The bidirectional ObjectServer Gateway determines the direction of the resynchronization by using the ActingPrimary property of the ObjectServer. This property setting is updated solely by automations, and requires no user intervention.
Reducing resynchronization time
To reduce the time taken to resynchronize the contents of one ObjectServer to another after the recovery of a primary or backup ObjectServer, or a bidirectional ObjectServer Gateway, you can configure the gateway to resynchronize only those events that have changed since the failure occurred.
Configuring controlled shutdown of an ObjectServer
You can configure a controlled shutdown of any ObjectServer such that pending changes are forwarded to IDUC clients before the ObjectServer shuts down. This minimizes the possibility of data loss on shutdown.
Configuring proxy servers for failover
The proxy server failover setup requires the Tivoli Netcool/OMNIbus basic failover architecture, and the following additional components: a primary proxy server and a backup proxy server.

Parent topic: Multitiered architecture and high availability

Related concepts:

Configuring and deploying a multitiered architecture

Configuring failback operations for unidirectional ObjectServer Gateways