1.6. Redundant GCaps: high availability

1.6.1. Introduction

High Availability enables two GCaps to be installed in redundancy so that the flows captured are not lost in the event of a GCap failure or shutdown.

To implement high availability, two GCaps must be installed on a network that communicate with a single GCenter.

In the event of a failure on one of the two GCaps, the other one takes over to allow the service to continue to function while it is being repaired.


1.6.2. How high availability works

1.6.2.1. Prerequisites

Configuration must be identical on both GCaps, otherwise the messages exchanged will not be considered valid.


1.6.2.2. Basic assumption

A GCap can be either leader or follower.

Only the GCap leader can send eve logs and files to the GCenter.

The GCap follower stores the eve logs and files on its file system.

Note

Retention time is 1 hour for the GCap follower.

When a GCap becomes the leader, it sends all the eve logs and files it stored on its file system.

There is no preemption mechanism: if a GCap is the leader, it will remain so as long as its status is healthy.


1.6.2.3. Electing the leader

The GCaps communicate with each other, electing the GCap leader and the GCap follower.

Electing the leader GCap is the one with the lowest ID: partly linked to the start date.

Avertissement

If the GCaps fail to communicate, then they both become `leader'. If this happens, the data is duplicated on the system.

Note

This behaviour is normal because a GCap cannot stop operating without the certainty that another GCap is leader.


1.6.2.4. Failure of a GCap

If the leader GCap fails, the follower GCap automatically becomes the leader GCap.

When the failed GCap becomes functional again, it was and remains the follower.

If the follower GCap fails, the leader GCap remains the leader.

When the failed GCap becomes functional again, it becomes the follower.


1.6.3. Using and configuring high availability

For more information, please refer to Redundant GCaps: high availability.