High Availability

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

This is the time when the server reported its state for the last time. 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 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 responds to the commands over the control channel.

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

Finally, an unknown control status may be signalled upon the server's startup, when the information about its actual status is not yet available.

The heartbeat status reports whether or not the server responds to the heartbeat commands from its partner. The heartbeat commands are exchanged between the partners regularly to check if the servers remain operational and to gather their current states and act accordingly.

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

A failed status occurs when the recent attempt to send the heartbeat to the server fails. In this case, we say that the partners are in the communication-interrupted state. They may be in this state temporarily if the communication problem is transient. If the communication is interrupted longer, it may trigger the failover procedure, resulting in the partner's transition to the partner-down state.

An unknown status may sometimes occur when the servers haven't tried to exchange the heartbeats yet.

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 no longer participates in the HA setup because of too-high clock skew.
  • 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, it is typically a single scope shown. There may be two scopes shown if a load-balancing server is currently serving all DHCP clients when its partner is down. There may be no scopes shown when it is a standby server in the hot-standby mode, because such a server is not responding to any DHCP queries, but 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 went 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 server with which the partner server is unable to communicate via ha-heartbeat. It includes both unacked clients and the clients for which the secs field or elapsed time option is below the max-ack-delay.

This is a total number of packets directed to the server with which the partner 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 the previous queries.

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

It is a 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.