High availability#
A Replicator instance can be paired with a secondary instance to create a high-availability pair that ensures uninterrupted flow data replication. Configuration data is synced between the primary and secondary instances for seamless failover.
Note
Any unpaired headless deployment without saved profiles can be set as a secondary instance in an HA pair.
Multi-network configuration#
When the primary and secondary Replicator instances are on different subnets (i.e., a virtual IP address cannot be used), the flow data to be replicated must be sent to both Replicator instances.
After a high availability pair is set up in this mode, the primary instance continuously sends UDP heartbeat packets to the secondary instance (1 packet per second). If the secondary fails to receive two consecutive heartbeat packets, it immediately starts replication. Once a heartbeat packet is received from the primary instance again, the secondary syncs any configuration updates, stops replication, and reverts to the standby state.
Note
Multi-network mode is the default high-availability configuration. If the primary and secondary Replicator instances are on the same network, enabling virtual IP/single-network mode is recommended.
Enabling multi-network HA on a Replicator#
To create a multi-network HA pair, follow these steps:
View instructions
Go to Admin > Resources > Replicators, and then click on the name of the Replicator instance to use as the primary.
In the Replicator configuration tray, toggle the High Availability switch to On (will not be displayed if no secondary instances are available).
Select the Replicator instance to use as the secondary in the Secondary IP dropdown.
Click Save to create the HA pair.
After the multi-network HA pair has been saved, configure all exporters to send flow data to both the primary and secondary instances.
Single-network configuration#
When the primary and secondary Replicator instances are on the same network, they can receive flow data packets via a shared virtual IP address.
After a high-availability pair is set up in this mode, the availability of the primary and secondary instances is monitored using the Virtual Router Redundancy Protocol (VRRP). If the primary Replicator instance becomes unavailable, the specified virtual IP address is immediately reassigned to the secondary instance, which then starts replication (handover typically takes ~1 second). Once the primary becomes available again, it re-assumes responsibility for the IP address and resumes replication after a user-defined delay (see instructions below).
Enabling virtual IP HA on a Replicator#
View instructions
Go to Admin > Resources > Replicators, and then click on the name of the Replicator instance to use as the primary.
In the Replicator configuration tray, toggle the High Availability switch to On.
Select the Replicator instance to use as the secondary in the Secondary IP dropdown.
Enable Virtual IP, and then enter the following details in the provided fields:
Virtual IP address: IP address to be shared between the primary and secondary instances
Virtual router ID: Virtual router ID to assign to the HA pair (must be unique to the pair to avoid conflicts with other software devices using VRRP)
Failover delay: Length of time that the primary instance must be online again before it takes over the virtual IP and replication (to avoid flapping)
Note
The failover delay is meant to allow all services on primary instance to fully restart after a reboot/outage. A delay of at least 2 minutes is recommended (default: 5 minutes).
Click Save to create the HA pair.
After the VIP HA pair has been saved, configure all exporters to send flow data to the virtual IP address specified.
Reverting HA pairings#
To revert paired Replicator instances back to single appliances, toggle off High Availability for the primary instance in the Admin > Resources > Replicators configuration tray.
This will unpair the instances and allow them to be used as single deployments again. The primary instance will retain all profiles, collectors, and other settings previously applied, and the secondary instance will be reverted to its unused, post-deployment state.