HA Pair Role Consistency Checker
Check HA peer snapshots for ownership drift, standby readiness, stale synchronization and heartbeat failures with service and priority evidence.| Group | Service / VIP | Nodes | Active-up | Standby-up | Sync | Verdict | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.group }} | {{ row.service }} | {{ row.node_count }} | {{ row.active_up }}/{{ expected_active_up }} | {{ row.standby_up }}/{{ minimum_standby_up }} | {{ row.sync_summary }} | {{ row.verdict }} |
| Group | Node | Role | State | Priority | Sync | Heartbeat | Flags | Copy |
|---|---|---|---|---|---|---|---|---|
| {{ row.group }} | {{ row.node }} | {{ row.role_label }} | {{ row.state_label }} | {{ row.priority_label }} | {{ row.sync_label }} | {{ row.heartbeat_label }} | {{ row.flags }} |
| Severity | Group | Node | Check | Evidence | Next step | Copy |
|---|---|---|---|---|---|---|
| {{ row.severity }} | {{ row.group }} | {{ row.node }} | {{ row.check }} | {{ row.evidence }} | {{ row.next_step }} |
A high-availability pair can look redundant in an inventory while being unable to take over cleanly. The current owner may be down, both peers may claim ownership, the standby may be unavailable, or the control link may be stale. A useful review therefore compares role, state, synchronization, heartbeat, service identity, and election priority from the same snapshot.
Active and standby describe responsibility, not health. An active peer that reports a degraded or down state is not a healthy owner, and a standby that is up may still be unsafe for failover if its configuration or sessions are stale. Priority is another clue rather than proof because products differ in whether higher or lower values win, whether preemption is enabled, and whether an operator has pinned the owner.
- Ownership evidence checks how many up peers currently claim the active role.
- Readiness evidence checks whether enough standby peers are up and whether heartbeat and synchronization reports are usable.
- Consistency evidence catches mixed virtual service identifiers, duplicate node rows, priority conflicts, and asymmetric preemption settings.
The snapshot must represent one point in time. Combining rows collected before and after a failover can manufacture split ownership or hide a transient outage. Even a clean snapshot cannot prove quorum, fencing, storage locking, route convergence, replicated data, or application readiness; those checks still belong in the live HA platform.
How to Use This Tool:
Collect peer observations from the same HA group and time window before setting the expected ownership model.
- Paste HA role rows as CSV or tab-delimited text. A header can name group, node, role, priority, VIP or service, state, sync, heartbeat, and preempt fields; without a header, use that order beginning with node.
- Set Expected active-up and Minimum standby-up for each group. The common active/passive expectation is one active-up and at least one standby-up.
- Choose Priority ownership to match the platform. Ignore priority when the snapshot lacks comparable numeric values or when manual ownership makes election order irrelevant.
- Set Sync stale after to the accepted lag in seconds, then inspect group health and the finding evidence. Confirm every critical or warning result against current device or controller state before failover.
Interpreting Results:
Critical at group level identifies an ownership or readiness condition such as the wrong number of active-up peers, too few ready standbys, or a claimed active peer that is not up. Review means the strongest group-level finding is Warning or Review. Clean means no group-level rule found drift in the supplied rows.
Always inspect peer findings as well as the group verdict. A down heartbeat is a Critical peer finding and stale synchronization is a Warning peer finding, but those peer checks do not raise the group verdict by themselves. Even a completely clean result is only a consistency check of the submitted snapshot. Verify live ownership, quorum, fencing, routing, replication, and application health before maintenance or a failover test.
Technical Details:
Rows are grouped by an explicit group field when present, otherwise by the VIP or service value, and finally under one default group. Role and state vocabulary is normalized so common vendor terms can be compared, but unrecognized values remain visible as review findings instead of being guessed.
Rule Core:
Peer-level findings are recorded before group-level ownership checks. The group verdict is the highest severity from the group-level pass; role, state, synchronization, and heartbeat findings remain separate peer evidence.
| Check | Condition | Severity |
|---|---|---|
| Role classification | Role is missing, unknown, or maintenance | Warning |
| State classification | State is missing or unknown | Warning |
| Synchronization | Known stale token, or numeric lag > the selected threshold | Warning |
| Heartbeat | Heartbeat normalizes to down | Critical |
| Member count | Rows < expected active-up + minimum standby-up | Warning |
| Active ownership | Active-up count ≠ the expected count | Critical |
| Standby readiness | Standby-up count < the selected minimum | Critical |
| Claimed active state | Any active-role peer is not up | Critical |
| Standby state | A standby-role peer is down | Warning |
| Service consistency | One group contains more than one nonblank VIP or service value | Warning |
| Duplicate evidence | A normalized node name appears more than once in a group | Warning |
| Priority ownership | An up peer outranks the sole active-up peer under the selected convention | Warning |
| Preempt consistency | Known peers mix preempt on and off | Review |
A numeric synchronization lag is fresh when it is less than or equal to the threshold and stale only when it is greater. Text such as synced, in sync, current, or healthy is treated as fresh; stale, out of sync, lagging, failed, or error is treated as stale. Missing and unrecognized synchronization values remain unreported or unknown rather than becoming failures.
Evidence Normalization:
| Normalized value | Representative accepted terms |
|---|---|
| Active | active, primary, master, owner |
| Standby | standby, passive, secondary, backup, spare |
| Up | up, healthy, ready, running, normal |
| Down | down, offline, failed, fault, dead, unavailable |
| Degraded | degraded, warning, impaired, partial |
Priority comparison runs only when exactly one active-up peer exists, more than one peer is up, and priority checking is enabled. Under the higher-wins setting, a larger numeric value outranks the active owner; under lower-wins, a smaller value does. A missing active priority produces a Review finding instead of an inferred result.
Limitations and Privacy Notes:
HA inventory stays in browser memory and is not added to the shareable URL. Copied or downloaded evidence can still expose internal node names, service addresses, priorities, and operating state.
- No devices, controllers, clusters, or monitoring systems are contacted.
- Up to 100 peer rows and 100,000 source characters are accepted; every useful review needs at least two peer rows.
- Platform-specific quorum, fencing, election, synchronization, and preemption semantics can differ from these general consistency rules.
References:
- Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6, RFC Editor, April 2024.