High Availability

This Server Partner
{{ statusRow.relationship.name }}
{{ column.value }} at
{{ statusRow.title }}

This is the time when the server last reported its state; it is not necessarily the time when the state information was refreshed in the UI. The presented state information is typically delayed by 10 to 30 seconds because it is cached by both the Kea servers and the Stork backend. Caching minimizes the performance impact on the DHCP servers reporting their states over the control channel.

This is the duration between the "Status Time" and now, i.e. it indicates how long ago the server reported its state. A long duration indicates that there is a communication problem with the server. The typical duration is between 10 and 30 seconds.

An online control status indicates that the server is responding to commands over the control channel.

An offline control status indicates that the server is not responding and may be down.

The unknown control status may appear during the server's startup, when the information about its actual status is not yet available.

The heartbeat status reports whether the server is responding to the heartbeat commands from its partner. Heartbeat commands are exchanged between the partners regularly to check whether the servers remain operational, and to gather and respond to their current states.

An OK status is desired at all times. It indicates a healthy heartbeat communication with the server.

A failed status occurs when the most recent attempt to send a heartbeat to the server fails. In this case, the partners enter the communication-interrupted state. They may recover from this state if the communication problem is transient. If communication is interrupted for a longer period, the failover procedure is triggered, resulting in the partner's transition to the partner-down state.

An unknown status may occur when the servers have not yet tried to exchange heartbeats.

The following are the possible server states:

  • hot-standby - normal operation in the hot-standby mode.
  • load-balancing - normal operation in the load-balancing mode.
  • passive-backup - the server has no active partner, unlike in the load-balancing or hot-standby mode. This server may be configured to send lease updates to the backup servers, but there is no automatic failover triggered in case of a failure.
  • waiting - the server is booting up and will try to synchronize its lease database.
  • syncing - the server is synchronizing its database after a failure.
  • ready - the server has synchronized its lease database and will start normal operation shortly.
  • terminated - the server is no longer participating in the HA setup because the clock skew is too high.
  • maintained - the server is under maintenance.
  • partner-maintained - the server is responding to all DHCP queries while its partner is in maintenance.
  • unavailable - communication with the server failed. It may have crashed or have been shut down.

This is a list of HA scopes currently being served by this server. If the server is responding to the DHCP queries as a primary or secondary in the load-balancing mode or as a primary in the hot-standby mode, there is typically a single scope shown. Two scopes may be shown if a load-balancing server is currently serving all DHCP clients while its partner is down. There may be no scopes shown when a standby server is in hot-standby mode, because such a server is not responding to any DHCP queries; instead, it is passively receiving lease updates from the primary. The standby server will start serving the primary server scope in the event of the primary failure.

This is the last time when the server transitioned to the partner-down state because its partner was considered offline as a result of an unexpected termination or shutdown.

This is the number of clients considered unacked by the partner. This value is only set when the partner has lost heartbeat communication with this server and has started the failover procedure, by monitoring whether the server is responding to DHCP traffic. The unacked number indicates clients that have been trying to get leases from this server longer than the time specified by the max-ack-delay configuration parameter.

This is the total number of clients trying to get new leases from the partner server, while the current server is unable to communicate with its partner via ha-heartbeat. This figure includes both unacked clients and clients for which the secs field or elapsed time option is below the max-ack-delay.

This is the total number of packets directed to the partner server, while the current server is unable to communicate using ha-heartbeat. It may include several packets from the same client who tried to resend a DHCPDISCOVER or Solicit after the server failed to respond to previous queries.

This shows a progress bar for the failover procedure. When it hits 100%, the server considers its partner offline, and transitions to the partner-down state. The progress is calculated from the number of unacked clients relative to the maximum number of unacked clients.

This is summary text describing the status of the HA setup.

{{ column.value }} at
Status refresh in {{ refreshCountdown }} s.
High Availability is not enabled on this server.