Zedmos

5.10 High Availability

Two appliances acting as one, so that a failure of either is something users do not notice. It is built from three independent layers, and understanding that they are independent is most of understanding high availability:

LayerDoesConfigured in
CARPA shared virtual address, owned by whichever node is master. Clients talk to that address and never know which box answers.Network → Virtual IPs
pfsyncCopies the firewall's connection state between nodes, so existing connections survive a failover instead of being reset.An interface dedicated to the pair
Configuration syncPushes configuration from the master to the backup, so the backup is a copy rather than a second box you also have to maintain.This page

A pair that has CARP but no state sync fails over with every connection dropping. A pair with both but no configuration sync fails over onto a backup whose rules are months old. All three, or you have not finished.

Settings — /m/core/hasync

High Availability: Settings
High Availability: Settings

On the master, this page says where the backup is and what to send it: the backup's address, the credentials to log in with, and the list of sections to synchronise.

The section list is deliberate, not "everything": some settings must differ between the nodes — each node's own interface addresses, its hostname, its CARP priority. Those stay node-local and are never pushed. Everything else you tick is copied whenever it changes.

Configure synchronisation in one direction only. Both nodes pushing to each other is how two boxes overwrite each other's changes. The master syncs to the backup; the backup syncs to nobody.

Status — /ha-status

High Availability: Status
High Availability: Status

The pair on one page:

  • This node's role — master or backup, from CARP's point of view.
  • Configuration sync — when it last ran, what it sent, and whether it succeeded. A sync that has been failing quietly for weeks is the failure mode this page exists to prevent.
  • CARP — each virtual address and which node owns it. A healthy pair shows every address owned by the same node; addresses split across nodes mean the nodes cannot hear each other.
  • Services on the backup — what is running over there.

Use this page after every change to the pair, and again after every failover test. And do test: a failover that has never been rehearsed is a plan, not a capability.