Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

ECA High Availability and Resilience

Overview​

The ECA cluster uses an active-active-active design: every node in the cluster processes and analyzes audit data simultaneously, rather than one node acting as a passive standby. This is implemented using dedicated Docker containers that each perform a specific function on every node.

This design tolerates multiple container failures, both within a single node and across nodes in the cluster, while continuing to process audit and threat-detection events.

How event processing is distributed​

  • Audit messages are load-balanced across all nodes in the cluster.
  • Each Active Directory user is hashed and assigned to a single node in the cluster, so that a given user's behavior pattern is always processed by the same node — this keeps per-user detection state consistent.
  • If a node goes down, another node in the cluster automatically takes over Active Directory user processing for the failed node's assigned users.

This provides more than a single point of failover redundancy, both within a node (container-level failures) and between nodes (full node failures), and keeps event processing running under most common failure conditions.

Cluster operational requirements​

The ECA cluster remains operational as long as 2 of its 3 nodes are running and able to reach the HDFS cluster database. This 2-of-3 quorum requirement is the key operational threshold to keep in mind when planning maintenance windows or responding to node failures — see ECA Cluster Operational Procedures for safe shutdown, restart, and single-node recovery steps.

See Also​