Configuring automated failover and failback
Tivoli Netcool/OMNIbus supports automated failover and failback of ObjectServers. In this mode, a backup ObjectServer holds a replica of the event data and automatically takes over all operations of the primary ObjectServer, such as automation control, when the primary ObjectServer goes down.
Failover occurs when applications connect to the backup ObjectServer when they lose connection to the primary ObjectServer. The failback function enables applications to reconnect to the primary ObjectServer when it becomes active again.
A bidirectional ObjectServer Gateway is used to replicate the event data between the primary and backup ObjectServers. The gateway has active connections to both ObjectServers and is aware of the status of each ObjectServer. This gateway uses signal notifications to inform each ObjectServer in the failover pair setup, when its counterpart fails or restarts. Messages are also written to the ObjectServer log file when the signals are raised. The message logging level on failover is ERROR, whereas for failback, the level is INFO.
- Signals: gw_counterpart_down and gw_counterpart_up
- Procedures: automation_disable and automation_enable
- Triggers: backup_startup, backup_counterpart_down, and backup_counterpart_up. These triggers are supplied as disabled in the $NCHOME/omnibus/etc/automation.sql file, which is one of the database initialization files.
To enable automated failover and failback, the backup_startup, backup_counterpart_down, and backup_counterpart_up triggers in the $NCHOME/omnibus/etc/automation.sql file must be enabled either before or after running nco_dbint to create the ObjectServers. You can enable the triggers before running nco_dbint by editing the automation.sql file. You can enable the triggers in an existing ObjectServer by using the ALTER TRIGGER command, or by using Netcool/OMNIbus Administrator.