6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up

HA Mode in Detail

High Availability (HA) is the simplest and most widely deployed ClusterXL mode. One member is Active and forwards every packet that arrives at the cluster VIP; the other member(s) are Standby — fully booted, running, and synchronized, but not forwarding traffic. If the Active member fails, the Standby member with the highest priority becomes the new Active member and starts forwarding. The cluster VIP and cluster MAC move with the Active role, so the upstream router does not need to be reconfigured.

HA mode is a good default for most production deployments because it has the fewest moving parts:

• It works with all routers and switches — the upstream router only ever ARP-resolves the cluster VIP to one member's MAC at a time, so no multicast support is required.
• It is the only mode that allows State Synchronization to be disabled (although in practice you enable it for stateful failover).
• The cluster can survive the failure of any single member, and recovery is deterministic because priority decides which Standby member takes over.

Primary Up vs Active Up

The two HA sub-modes differ only in what happens when the failed Active member comes back online:

Primary Up (Preemptive)

In Primary Up mode, the member with the highest configured priority always becomes Active when it is healthy. If a higher-priority member fails and then recovers, it preempts the current Active member and takes the Active role back. This is the behavior you want when one member is the "preferred" Active gateway — for example, because it has more throughput, or because of a licensing preference.

Trade-offs:

• Predictable: the highest-priority member is always Active when healthy.
• Risk: each recovery triggers a failover, which is a momentary blip for traffic. In a flapping environment (a member that keeps going up and down), Primary Up will keep flipping the cluster, which is worse than staying on the working member.

Active Up (Non-Preemptive)

In Active Up mode, the current Active member stays Active even after a higher-priority member recovers. Failover happens only when the Active member actually fails. This is more stable in environments where you do not want traffic to bounce back and forth when a recovered member rejoins the cluster.

Trade-offs:

• Stable: no failover on recovery, so no traffic blip when the failed member returns.
• Less predictable: after a failover, the Active role may sit on a lower-priority member indefinitely until you manually fail back or until that member also fails.

How Failover Works in HA

A failover in HA mode is the transfer of the Active role from one member to another. It is triggered when the Active member's Critical Devices (PNOTEs) report a problem, when the member loses connectivity (peer sees it as LOST), or when an administrator manually fails the member over with clusterXL_admin down (the recommended manual-failover method because it does not disable Delta Sync).

When the Active member goes DOWN:

1. The Standby member with the highest priority transitions to ACTIVE.
2. The new Active member sends Gratuitous ARP (GARP) requests for the cluster VIP, associating the VIP with its own unique MAC so that downstream switches and routers refresh their ARP/MAC tables immediately.
3. State Sync (if enabled) has already populated the new Active member's connection tables, so existing connections continue without being reset.
4. The failed member transitions to DOWN (or LOST if the peer can no longer reach it at all).

Configuring HA

HA is configured in two places:

• SmartConsole — edit the cluster object, choose Cluster Mode: High Availability, and per member set the priority that decides which Standby member becomes Active on failover. Lower number = higher priority by convention in the cluster member list.
• Gaia Clish / WebUI — enable ClusterXL on each member, select the cluster interfaces and the sync interface, and configure the HA sub-mode (Primary Up or Active Up). In Clish, set cluster member admin down triggers a controlled failover; show cluster state reports the current member state.

The two sub-modes are cluster-wide — all members share the same setting. You cannot have Primary Up on one member and Active Up on another.

When to Choose HA

Choose HA mode when:

• Your switches do not support multicast MAC addresses in ARP replies (common with some access-layer switches).
• You do not need throughput beyond what one gateway can provide.
• Operational simplicity is more important than parallel scaling.
• You want the option to disable State Sync for debugging or for very low-latency environments where sync overhead matters (rare).

Choose Primary Up specifically when you have a clear preferred Active member (for example, a higher-throughput appliance). Choose Active Up when stability matters more than which member is Active — most production deployments use Active Up to avoid failover churn during recovery.