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.