Clustering & HA
Fidwyn clusters active-active to 24 nodes. Every node serves traffic behind one virtual IP; state replicates underneath; a lost node self-heals, and failover between sites is a deliberate, operator-controlled action, never a silent switch.
- Two or more appliances brought up from the same golden image (Get started), on the same low-latency network.
- A virtual IP reserved for the cluster, since clients reach the cluster through the VIP, not a node address.
- Matching product versions on every node.
- The first (primary) node licensed; enrollment tokens carry the primary’s address to joining nodes.
Enroll the cluster ¶
Build the cluster from one primary outward. There is no cold standby to promote later; every node is live.
- Initialize the primary. On the first node, open System Settings → High Availability and initialize the cluster, reserving the virtual IP that clients will use.
- Generate an enrollment token. The primary issues a one-time token with its own address encoded inside, so joining nodes need no manual IP entry.
- Join each node. Bring up another appliance from the golden image (Get started), open High Availability → Join, and paste the token. The node enters the mesh, begins replicating state, and starts serving traffic, usually within a minute.
- Repeat up to 24 nodes. Add a Site label to group nodes by location for planned failover.
Replicate state (Postgres, Vault, Redis) ¶
- Postgres streams to role-aware standbys, so committed audit and configuration data exists on more than one node.
- Vault replicates as a multi-voter Raft quorum; keep an odd number of voters so the credential store keeps a majority, and stays available, through a node loss.
- Redis replicates the cache and session layer.
A VRRP-style mesh owns the virtual IP behind which every node's API gateway sits; clients keep talking to the VIP regardless of which node answers.
Self-healing vs. planned failover ¶
Draw the line clearly between the two:
- Automatic, within a cluster. A failed container or process is restarted locally in seconds, and traffic stays on the healthy nodes behind the VIP. No operator action, no data loss.
- Manual, between sites. Moving the active role to another site is a deliberate, planned operation an administrator performs (for maintenance or a declared disaster). Fidwyn does not silently fail a whole site over on its own; you decide when the VIP and primary role move, so a transient link blip never triggers an unwanted cross-site switch.
Read node health (High Availability) ¶
The High Availability console reports, per node: memory, disk, connection count, the master link, the mesh IP, replication state, and the Raft quorum. Watch it after every join to confirm the new node reached replicating/healthy before you rely on it; see System status for the distinction from Fidwyn-operated services.