The IBM® Tivoli® Netcool/OMNIbus product can be deployed in a multitiered configuration to increase performance and event handling capacity.
- The collection tier includes the ObjectServers to which probes connect. In a high-availability architecture, primary and backup pairs of ObjectServers are included in this tier. Each ObjectServer in the collection tier is connected to an ObjectServer in the aggregation tier by using a unidirectional gateway.
- The aggregation tier includes up to two ObjectServers if you are using a high-availability architecture. The ObjectServers are connected by a bidirectional gateway. The bulk of the event processing occurs in the aggregation tier.
- The display tier includes one or more ObjectServers. They are connected to an ObjectServer in the aggregation tier by using a unidirectional gateway. The Netcool/OMNIbus desktop event list users and web GUI users connect to ObjectServers in this tier. The operator connects their Netcool/OMNIbus Desktop UI to the display tier in dual-server desktop mode. Events are retrieved from the display ObjectServers, but updates made to events go to both the display and the aggregation tiers.
High-availability can also be achieved in a single-tier environment by having a primary and backup ObjectServer and a bidirectional gateway between them. In a single-tier architecture, the probes and user interfaces connect directly to these ObjectServers and the ObjectServers perform the collection, aggregation, and display functions.
The IBM Tivoli Monitoring triggers are assigned to the primary_only trigger group. In a high-availability Netcool/OMNIbus architecture, the standard Netcool/OMNIbus automations enable the triggers in the primary_only trigger group on the acting primary ObjectServer and disable them on the backup ObjectServer.
For more information about the Netcool/OMNIbus ObjectServer multitiered and high-availability architecture and setup instructions, see the Netcool/OMNIbus information center: http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.tivoli.namomnibus.doc/welcome_ob.htm.
You can also set up peer-to-peer failover mode for Netcool/OMNIbus probes to reduce event loss. Two instances of a probe can run simultaneously in a peer-to-peer failover relationship. One instance is designated as the master; the other instance acts as a slave and is on hot standby. If the master instance fails, the slave instance is activated. For more information about configuring and using master and slave probes for high availability, see the Netcool/OMNIbus information center: http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.tivoli.namomnibus.doc/welcome_ob.htm.
In Netcool/OMNIbus multitier and high-availability architectures, the Tivoli Enterprise Monitoring Servers are configured to forward events to the ObjectServers via the probes. If probe failover mode is used, you must configure situation events in IBM Tivoli Monitoring with multiple event destinations – one destination to the master probe and a second destination to the slave probe.
In a multitiered architecture, IBM Tivoli Monitoring provides triggers to add to the collection tier, database schema updates and triggers for the aggregation tier, and database schema updates for the display tier. The gateways also must be updated with mapping entries. In this architecture, the IBM Tivoli Monitoring Situation Update Forwarder is installed on each ObjectServer in the aggregation tier.
In a single-tier high-availability architecture, the IBM Tivoli monitoring triggers and database schema updates are applied to the primary and backup ObjectServers and mapping entries are configured for the bidirectional failover gateway between the ObjectServers. The IBM Tivoli Monitoring Situation Update Forwarder is installed on each ObjectServer.
Uses
You can use the Netcool/OMNIbus multitiered architecture if you need to add scalability to your Netcool/OMNIbus environment to increase performance and event handling. High availability can be added for the ObjectServers in your single-tier and multitier architectures so that your environment can continue to operate at full capacity (and with minimal event loss) in the event of ObjectServer failure.
Adding peer-to-peer failover for the probes can be used to reduce event loss in the event of a probe failure.