From: Marcin Siodelski Date: Thu, 10 May 2018 10:02:52 +0000 (+0200) Subject: [5478] Addressed most of the review comments. X-Git-Tag: trac5549a_base~34^2~6 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b2ff311bdb0c408a4e4607da7263d4a63b01d9c5;p=thirdparty%2Fkea.git [5478] Addressed most of the review comments. Focusing on minor additions and corrections. --- diff --git a/doc/guide/hooks-ha.xml b/doc/guide/hooks-ha.xml index 9d98ac1fb7..7d02d4e047 100644 --- a/doc/guide/hooks-ha.xml +++ b/doc/guide/hooks-ha.xml @@ -7,13 +7,18 @@ -->
- libdhcp_ha: High Availability + ha: High Availability + + This section describes the High Availability hooks library, which can be + loaded on a pair of DHCPv4 or DHCPv6 servers to increase reliability of + the DHCP service in case of outage of one of the servers. This library + is only available to ISC customers. + High Availability (HA) of the DHCP service is provided by running multiple cooperating server instances. If any of these instances becomes - unavailable for whatever reason (DHCP software crash, control agent - software crash, power failure, hardware - failure), a surviving + unavailable for whatever reason (DHCP software crash, Control Agent + software crash, power outage, hardware failure), a surviving server instance can continue providing the reliable service to the clients. Many DHCP servers implementations include "DHCP Failover" protocol, which most significant features are: communication between the servers, partner @@ -98,10 +103,10 @@ the partner server doesn't respond to the ha-heartbeat command longer than configured amount of time, the communication is considered interrupted and the server may (depending on the configuration) - use additional measures to verify if the partner is still operating. - If it finds that the partner is not operating, the server transitions - to the partner-down state to handle the entire - DHCP traffic directed to the system. + use additional measures (desribed further in this document) to verify if + the partner is still operating. If it finds that the partner is not + operating, the server transitions to the partner-down + state to handle the entire DHCP traffic directed to the system. In this case, the surviving server continues to send the ha-heartbeat command to detect when the partner wakes @@ -176,12 +181,17 @@ synchronizes the database.. - Whether the server responds to the DHCP queries and which + Whether the server responds to the DHCP queries and which queries it responds to is a matter of the server's state, if no administrative action is performed to configure the server otherwise. The following table provides the default behavior for various states. + The DHCP Server Scopes denotes what group + of received DHCP queries the server responds to in the given state. + The in-depth explanation what the scopes are can be found below. + + Default behavior of the server in various HA states @@ -246,8 +256,6 @@
- - The DHCP service scopes require some explanation. The HA configuration must specify a unique name for each server within the HA setup. This document uses the following convention within @@ -499,7 +507,7 @@ auto-failover - a boolean value which denotes whether the server detecting a partner's failure should - automatically start serving its clients. + automatically start serving partner's clients. @@ -844,8 +852,19 @@
ha-sync command The ha-sync is issued to instruct the - server to synchronize the local lease database with the - selected peer. The database synchronization may be triggered for + server to synchronize its local lease database with the + selected peer. The server fetches all leases from the peer and + updates those locally stored leases which are older comparing to + those fetched. It also creates new leases when any of those + fetched do not exist in the local database. All leases that + are not returned by the peer but are in the local database are + preserved. The database synchronization is unidirectional, i.e. + only the database on the server to which the command has been + sent is updated. In order to synchronize the peer's database a + separate ha-sync has to be issued to that + peer. + + The database synchronization may be triggered for both active and backup server type. The ha-sync has the following structure (DHCPv4 server case): @@ -873,6 +892,15 @@ dhcp-enable to the peer to re-enable its DHCP service. + + The max-period value should be sufficiently + long to guarantee that it doesn't elapse before the synchronization + is completed. Otherwise, the DHCP server will automatically enable + its DHCP function while the synchronization is still in progress. + If the DHCP server subsequently allocates any leases during the + synchronization, those new (or updated) leases will not be fetched + by the synchronizing server leading to database inconsistencies. +