How Impact determines which events are processed on which server in a cluster

Body

It is often asked how Impact determines which events are processed on which server in an Impact cluster.  Here is a basic explanation.

When you have an Impact cluster, most often with 2 servers a primary server (PRI) and a secondary server (SEC), the SEC server provides 2 features:  Fail-over, where it takes over from the PRI, if it fails; and Load-balancing where some workload is run on the SEC server, as well as the PRI.

The load-balancing feature in an Impact cluster is probably better described as ‘load-sharing’ because it does not do anything to actively monitor what each server is doing and balance the workload.  What happens is; the event readers read events in blocks and places them on a queue for the event processors.  The event processors read the blocks of events, on a first come first served basis and then process them.  While the PRI does not have any precedence when it comes to reading the blocks of events, in practice the PRI is more likely to get there first because the event reader is also be running on the PRI.  If there are multiple blocks of events on the queue the 2 servers normally process them in turn.  This is why, when the workload is light, you may well see more policies running and events being processed on the PRI.

Note:  If an event reader has event locking enabled, for example:

Events from this event reader will only be processed on the PRI, to prevent events with the same event locking expression value being run at the same time on the PRI and the SEC.  This is a necessary design feature and cannot be overridden.

Note:  Policies that are started by policy activators are not run on the SEC server.  The policy activators only run on the PRI server and therefore they only run policies on the PRI.  The same applies to policies run from the GUI and from operator views.