High Availability

Overview

ZigiOps provides high availability to ensure that the integration could continue its operation in the event of a server failure or if it needs to be stopped for maintenance. The high availability solution consists of a Primary ZigiOps server and at least one backup ZigiOps server, which continues serving the integrations after a manual failover procedure.

We recommend that when you install the primary and backup servers, they should be comparable in hardware, memory, and performance.

There could be any number of ZigiOps servers prepared to take over from the Primary one, but only one could be active simultaneously. Suppose the failover is performed to the Backup ZigiOps server. In that case, the Primary one remains inactive until a further decision is made to manually return the operation state to it using the same procedure.

How It Works

ZigiOps is designed to integrate data with a minimum offline footprint related to the integration state, which consists of several runtime files in a size of a few kilobytes. It does not generate any big data on the file system or in any databases, making it easy to replicate the integration state to the Backup server and continue from where the Primary one stopped. Everything needed for a Backup ZigiOps server to take over from a Primary one is to synchronize their runtime files.

Once the Backup ZigiOps server has the runtime files from the Primary one, it is ready to become active and continue the integration, avoiding gaps in data integration. You could synchronize the runtime files manually by copying them over to the Backup Server or configuring a shared network directory to store them (Linux only).

The passive (usually the Backup) ZigiOps server must always be stopped while another ZigiOps server is active (usually the Primary one).

Requirements

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

• The installed ZigiOps version on the Primary server is the same as the Backup server.

• Integration configuration is maintained in sync between each server

• Active licenses on each Primary and Backup ZigiOps server

• Only one ZigiOps server is active at the same time

• A Load Balancer VIP for each port used in an integration action with Listener type of trigger. For more details, please check the High Availability for Listener Triggers page.

Configuration

The below steps assume that the Primary ZigiOps server is already configured with the integrations it will run, and relevant licenses are applied on each ZigiOps instance.

1. Install the same version of ZigiOps on the Backup server as it is on the Primary one

2. Stop ZigiOps on the Backup server

3. Stop ZigiOps on the Primary server

4. Synchronize integration configuration from the Primary ZigiOps to the Backup one by copying over the following directory

   • Windows → <ZigiOps>\conf

   • Linux → <ZigiOps>/conf

5. Start ZigiOps on the Primary server

6. Leave the Backup ZigiOps service down.

   • You should maintain the above-described integration configuration in sync. The recommendation is to sync the files again anytime a change is made on the active ZigiOps server. The example scenario for using Network Storage also covers the automatic synchronization of the integration configuration.

Failover

The below steps explain how to move the active ZigiOps between the Primary and the Backup servers.

1. Stop the Primary ZigiOps server.

2. Synchronize the runtime files by copying over the following files to the Backup server:

   • Windows → <ZigiOps>\conf\settings\runtime

   • Linux → <ZigiOps>/conf/settings/runtime

3. Start ZigiOps on the Backup server.

   • In some cases of a disaster, it is possible that the ZigiOps Server (on the OS level) will not be available to copy the runtime files from it. For such cases, it is recommended to consider constant sync of the runtime files like the example scenario for using Network Storage on Linux systems. If that's not an option and such a disaster happens, the recommendation is to delete the runtime files on the Backup server and start ZigiOps clean. This way, it will continue integration operation but may result in a gap in data for the period when the Primary one stopped and the Backup one started.