mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-30 13:37:55 +00:00
Code Issues Releases Wiki Activity

[#2202] Additional text edits after review

Browse Source
This commit is contained in:
Suzanne Goldlust
2021-12-02 20:52:01 +00:00
committed by Thomas Markwalder
parent d2a51ab37e
commit 6c36dc782d
1 changed files with 9 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
doc/sphinx/arm/hooks-ha.rst
View File

@@ -1685,7 +1685,7 @@ the servers while the other one continues to respond to DHCP queries.
When the first server is upgraded and back online, the upgrade can be performed for When the first server is upgraded and back online, the upgrade can be performed for
the second server. the second server.
A typical problem reported without early versions A typical problem reported with early versions
of the High Availability hook library was that the administrator did not of the High Availability hook library was that the administrator did not
have direct control over the state of the DHCP server. Shutting down have direct control over the state of the DHCP server. Shutting down
one of the servers for maintenance did not necessarily cause the other one of the servers for maintenance did not necessarily cause the other
@@ -1724,7 +1724,7 @@ state ``server1`` continues to send lease updates to ``server2`` until
the administrator shuts down ``server2``. ``server1`` now responds to all the administrator shuts down ``server2``. ``server1`` now responds to all
DHCP queries. DHCP queries.
The administrator can safely shut down ``server2`` in the The administrator can now safely shut down ``server2`` in the
``in-maintenance`` state and perform any necessary maintenance actions. While ``in-maintenance`` state and perform any necessary maintenance actions. While
``server2`` is offline, ``server1`` will obviously not be able to communicate ``server2`` is offline, ``server1`` will obviously not be able to communicate
with its partner, so it will immediately transition to the ``partner-down`` with its partner, so it will immediately transition to the ``partner-down``
@@ -1986,6 +1986,12 @@ from the surviving server does not reflect the failure. Resending the command
detects the failure once the surviving server has entered the ``partner-down`` detects the failure once the surviving server has entered the ``partner-down``
state. state.
.. note:
Always send the ``ha-heartbeat`` command to both active HA servers
to check the state of the entire HA setup. Sending it to only one of the
servers may not reflect issues with one of the servers that just began.
.. _command-ha-status-get: .. _command-ha-status-get:
The ``status-get`` Command The ``status-get`` Command
@@ -2152,7 +2158,7 @@ The ``ha-maintenance-cancel`` Command
This command is used to cancel the maintenance previously initiated using This command is used to cancel the maintenance previously initiated using
the ``ha-maintenance-start`` command. The server receiving this command the ``ha-maintenance-start`` command. The server receiving this command
first sends ``ha-maintenance-notify``, with the ``cancel`` flag set will first send ``ha-maintenance-notify``, with the ``cancel`` flag set
to ``true``, to its partner. Next, the server reverts from the to ``true``, to its partner. Next, the server reverts from the
``partner-in-maintenance`` state to its previous state. See the ``partner-in-maintenance`` state to its previous state. See the
:ref:`ha-maintenance` section for details. :ref:`ha-maintenance` section for details.