]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/rados: edit t-mon.rst text 54349/head
authorZac Dover <zac.dover@proton.me>
Sun, 5 Nov 2023 12:28:39 +0000 (22:28 +1000)
committerZac Dover <zac.dover@proton.me>
Sun, 5 Nov 2023 16:06:41 +0000 (02:06 +1000)
Clarify the text in the "Clock Skew" section of
doc/rados/troubleshooting/troubleshooting-mon.rst.

Co-authored-by: Anthony D'Atri <anthony.datri@gmail.com>
Signed-off-by: Zac Dover <zac.dover@proton.me>
(cherry picked from commit 5496bd426f35c0ab91ae7d544ae92ed3b517c7eb)

doc/rados/troubleshooting/troubleshooting-mon.rst

index ca2f19631a84b42819ee7ed3d4b84d773e56a6d6..4ccdbc4ef99ed797eaf02f05ecf9857a90591b2e 100644 (file)
@@ -350,12 +350,13 @@ Inject a monmap into the monitor
 Clock Skews
 -----------
 
-The Paxos consensus algorithm requires tight time alignment. For this reason,
-clock skew among the monitors in the quorum can have a serious effect on
-monitor operation. The resulting behavior can be very puzzling. To avoid
-this kind of issue, run a clock synchronization tool on your monitor nodes:
-for example, ``Chrony`` or the legacy ``ntpd`` utility. Be sure to configure
-the monitor nodes with the `iburst` option and multiple peers:
+The Paxos consensus algorithm requires close time synchroniziation, which means
+that clock skew among the monitors in the quorum can have a serious effect on
+monitor operation. The resulting behavior can be puzzling. To avoid this issue,
+run a clock synchronization tool on your monitor nodes: for example, use
+``Chrony`` or the legacy ``ntpd`` utility. Configure each monitor nodes so that
+the `iburst` option is in effect and so that each monitor has multiple peers,
+including the following: 
 
 * Each other
 * Internal ``NTP`` servers
@@ -366,12 +367,12 @@ the monitor nodes with the `iburst` option and multiple peers:
    into initial synchronization.
 
 Furthermore, it is advisable to synchronize *all* nodes in your cluster against
-internal and external servers, and perhaps even against your monitors. ``NTP``
-servers should run on bare metal; VM virtualized clocks are not suitable for
-steady timekeeping. For more information, visit `https://www.ntp.org
-<https://www.ntp.org>`_.  Your organization might already have quality internal
-``NTP`` servers available.  Sources for ``NTP`` server appliances include the
-following:
+internal and external servers, and perhaps even against your monitors. Run
+``NTP`` servers on bare metal: VM-virtualized clocks are not suitable for
+steady timekeeping. See `https://www.ntp.org <https://www.ntp.org>`_ for more
+information about the Network Time Protocol (NTP). Your organization might
+already have quality internal ``NTP`` servers available.  Sources for ``NTP``
+server appliances include the following:
 
 * Microsemi (formerly Symmetricom) `https://microsemi.com <https://www.microsemi.com/product-directory/3425-timing-synchronization>`_
 * EndRun `https://endruntechnologies.com <https://endruntechnologies.com/products/ntp-time-servers>`_