High Availability

High Availability

EZ-Kea configures ISC Kea's High Availability hook (libdhcp_ha.so), which lets two or three Kea servers share lease state over HTTP and fail over automatically. See the Kea ARM's "High Availability" chapter for the underlying behaviour.

Find it under HA in the navbar. DHCPv4 and DHCPv6 are configured separately on the same page.

What EZ-Kea does and doesn't manage

Manages: the hook's entry in your config's hooks-libraries[] list and everything inside its high-availability parameters block — mode, this server's name, timers, and the peer list. Other hooks you have configured are left untouched.

Does not manage: the Kea Control Agent. HA peers talk to each other over HTTP through each server's Control Agent, which is a separate daemon with its own config file, outside EZ-Kea's scope. The peer URLs you enter here must match wherever each peer's Control Agent is actually listening. If HA doesn't come up, that mismatch is the first thing to check.

Hook library path

Defaults to the Debian/Ubuntu ISC package location:

/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so

RPM-based installs typically use /usr/lib/kea/hooks/libdhcp_ha.so. The path is an editable field rather than something EZ-Kea guesses, because getting it wrong means the hook silently fails to load. Confirm the file exists on each server before saving.

Modes

Mode	Behaviour
hot-standby	One server answers all traffic; the standby takes over on failure.
load-balancing	Both servers answer, splitting the client population.
passive-backup	The primary answers everything and pushes lease updates to backups, which never respond.

Peer roles

primary, secondary, standby, and backup. Valid combinations depend on the mode — load-balancing uses primary plus secondary, hot-standby uses primary plus standby, and passive-backup uses primary plus one or more backups.

Peer names may contain letters, digits, ., _, and -. Duplicate names are rejected.

Timers

Field	Meaning
Heartbeat Delay	Milliseconds between heartbeat probes to peers.
Max Response Delay	Milliseconds without a response before a peer is considered down. Must be at least 1.
Max Ack Delay	Milliseconds a client may wait before the partner is considered overloaded.
Max Unacked Clients	How many unacknowledged clients are tolerated before declaring the partner down.

All four are validated as non-negative integers before anything is written, and a form with any error saves nothing at all rather than a partially-valid config.

Live status

The HA page polls each daemon's UNIX control socket for ha-heartbeat, so what you see is the running daemon's own view of the world — not a re-read of the config file on disk.

This requires a control-socket to be configured in your Kea config and readable by the EZ-Kea service account. If the socket is missing or unreachable, the status panel says so rather than reporting a healthy state it can't verify.

For safety, the control channel is restricted to an allowlist of two read-only commands (ha-heartbeat and status-get). There's no path through EZ-Kea to send arbitrary commands to your DHCP daemons.

Disabling HA

Un-tick Enable HA and save. EZ-Kea removes the hook entry from hooks-libraries[], leaving your other hooks in place. As with any change, this only takes effect once you apply the configuration and reload.