High Availability for Listener Triggers

Overview

This page describes how HA works for integration actions based on the Listener type of triggers. If there are no Listener triggers in your integrations, you could skip that page. When you are unsure whether the Listener type of triggers is used in your integrations, you could check that by browsing through each action of the integration you have configured and checking the chosen trigger on the Source tab. It could be either "Polling" or "Listener."

Listener Trigger Example:

Integrations in which a “Listener” triggers are used OOTB:

• OBM events to ServiceNow incidents (CLIP)

• OBM events to Cherwell incidents (CLIP)

• OBM events to BMC Remedy incidents (CLIP)

• OBM events to Jira issues (CLIP)

How It Works

While the main Failover solution described on the High Availability page is applicable for any integration, when some or all of the integration actions are configured with Listener type of triggers and Failover is performed to a Backup ZigiOps server, logically, the host serving the Listener's endpoint is changed. In such cases, the 3rd party Integrated System must continue directing the HTTP requests to the active ZigiOps host.

In Integration Actions configured with Listener type of trigger, ZigiOps is the passive side of the integration, waiting to receive an HTTP request. This design allows putting a Load Balancer software before ZigiOps to automatically direct the HTTP requests to the active instance.

This way, the 3rd Party Integrated System doesn't need to know which ZigiOps host exactly serves its requests and results in an Automatic Failover. ZigiOps acts in active/passive mode; thus, the Load Balancer will always know which server is active based on its HTTP Health monitors and direct the HTTP requests accordingly.

Requirements

This scenario expands the main Failover solution described on the High Availability page. It has the same prerequisites and requires the ZigiOps servers to be configured the same way. 

• Equal hardware and OS used on both the Primary and the Backup ZigiOps server.

• Primary and Backup servers have installed the same version of ZigiOps

• Integration configuration is maintained in sync between each server - for info on how to automate this, please look at the Network Storage for Runtime Files page

• External Load Balancing software

• VIP for each network port used in an integration action

• HTTP Health Monitors

• Active licenses on each Primary and Backup ZigiOps server

• Only one ZigiOps server is active at the same time

Configuring Load Balancer VIP

1. Determine how many VIPs you would need for your scenario - review all of the integration actions configured with Listener type of triggers and note the port number used. You would need one VIP for each unique port number used for a listener. For example, if you have three actions configured with a Listener trigger on HTTPS and port 9090 and 1 action configured with Listener trigger on HTTP and port 9494, you would need 2 VIPs on the Load Balancer - HTTPS 9090 and HTTP 9494.

2. Configuring the VIP on the Load Balancer depends on the actual Load Balancing software used, but you could consider the following general notes:

   • Usually, there will be a pool containing all the ZigiOps servers included in the HA solution.

   • The forwarded requests need to preserve the original Host header

   • Forward Proxy is not supported

   • There are no restrictions for the load balancing method and no requirements for persistency.

3. Configure HTTP Health Monitor for each VIP on the Load Balancer

   • Type → Use the HTTP monitor type

   • Port → Configure the port used in an integration action, i.e., 9090

   • Send string → Use the GET method against a PATH used in an integration action, i.e.,/listener/omi

   • Receive string → The monitor should expect the successful response HTTP 200 OK

4. Once the LB configuration is all set, use the LB VIP in the 3rd Party Integration system instead of the listener's direct ZigiOps hostname and port number.

Failover

The below steps explain how to move the active ZigiOps between the Primary and the Backup servers when using a Load Balancer for integration actions triggered on HTTP Listeners.

• Stop the Primary ZigiOps

• Start the Backup ZigiOps

There should be only 1 ZigiOps instance active at the same time.