IBM Support

Netcool OMNIbus Gateway High Availability

Technical Blog Post


Abstract

Netcool OMNIbus Gateway High Availability

Body

In database, helpdesk and other Netcool OMNIbus gateways, there is no peer-to-peer functionality available for a master and slave gateway configuration as in probes. There is no officially supported method for gateway primary and secondary failover/failback and high availability. Instead, a highly available gateway is typically configured using a cold standby method. A cold standby gateway will run only when the primary gateway is down. Scripts will use nco_ping to check when the primary gateway is down and startup the cold standby gateway. Similar scripts will also check when the primary gateway is available again and shut down the cold standby.
 
 
There is an example configuration and scripts which describe the cold standby method for the JDBC gateway. The document is specific to the JDBC gateway, but the examples provided could be modified for other gateways as well. The high availability documentation for the JDBC gateway is available at
 

The cold stanby documentation for the JDBC gateway relies on the use of persistent storage which is available to both the primary and cold standby gateway with an NFS mount or SAN. The persistent storage along with the gateway resync minimizes event loss during gateway failover and failback. The persistent storage also prevents duplicate events from being passed by the gateway.
 
With the cold standby method and other gateways than the JDBC gateway, there would be a period of time during failover when the primary gateway is down and the cold standby gateway has not yet initialized when event loss could occurr. To minimize the event loss, a re-update trigger could be implemented. The re-update trigger would cause all pending events to be updated in the Object Server and to be sent to the gateway through Object Server IDUC (Insert, Delete, Update and Control notifications).
For example, with a helpdesk gateway that updates the TicketNumber field, the following trigger could be used to re-update events where the TicketNumber is not populated and the event has not been updated in the last 5 minutes:
 
create or replace trigger reticket_events
group custom_triggers
priority 1
comment 'Trigger updates for rows where TicketNumber is not populated and the event has not been updated in 5 minutes'
every 307 seconds
begin
       update alerts.status set TicketNumber = TicketNumber where TicketNumber = '' and StateChange < (getdate() - 300) ;
end;
 
For gateways where no Object Server field is updated by the gateway, the gateway can be configured with an AFTER IDUC DO statement to update a field in the Object Server when the gateway reads the event. For example, with a ODBC gateway set to update a field SentByGateway to 1 after IDUC, the following trigger could be used.
 
create or replace trigger reupdate_events
group custom_triggers
priority 1
comment 'Trigger updates for rows where SentByGateway is not 1 and the event has not been updated in 5 minutes'
every 307 seconds
begin
       update alerts.status set SentByGateway = SentByGateway where SentByGateway = 0 and StateChange < (getdate() - 300) ;
end;
 
 
 

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"","label":""}}]

UID

ibm11082079