все мои серверы ntpd отмечены фальцетом, почему?
У меня есть набор из четырех серверов ntpd, которые синхронизируют время с одного и того же сервера уровня 1. Но у некоторых клиентов все они отмечены фальцетом, почему?
remote refid st t when poll reach delay offset jitter
==============================================================================
x10.201.24.36 209.51.161.238 2 u 12 64 377 0.177 464.794 1.136
x10.201.13.99 209.51.161.238 2 u 37 64 377 0.148 463.427 0.541
x10.201.24.37 209.51.161.238 2 u 817 1024 377 0.174 462.235 0.143
x10.201.12.198 209.51.161.238 2 u 853 1024 377 0.158 462.151 302.364
*127.127.1.0 .LOCL. 10 l 48 64 377 0.000 0.000 0.004
Время от времени они выздоравливают, но почему это вообще происходит? Также другой вопрос, почему у меня такой большой зачет? Я попытался оставить только 1 ntp сервер, но смещение все равно не падает.
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.201.12.198 209.51.161.238 2 u 64 64 7 0.108 470.963 0.200
127.127.1.0 .LOCL. 10 l 136 64 14 0.000 0.000 0.001
Я запускаю CentOS 7, и все серверы находятся в одной сети.
ntp.conf:
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict lga-ntp03.pulse.prod
server lga-ntp03.pulse.prod iburst burst
restrict lga-ntp06.pulse.prod
server lga-ntp06.pulse.prod iburst burst
restrict lga-ntp05.pulse.prod
server lga-ntp05.pulse.prod iburst burst
restrict lga-ntp01.pulse.prod
server lga-ntp01.pulse.prod iburst burst
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
Обновление # 1 После удаления LOCL (благодаря @John Mahowald) мои серверы по-прежнему помечаются как фальцетик:
remote refid st t when poll reach delay offset jitter
==============================================================================
x10.201.24.36 209.51.161.238 2 u 886 1024 7 0.177 -330.92 0.172
*10.201.13.99 209.51.161.238 2 u 773 1024 17 0.203 -152.68 0.090
x10.201.24.37 209.51.161.238 2 u 750 1024 17 0.167 94.101 0.468
x10.201.12.198 209.51.161.238 2 u 409 1024 17 0.129 51.831 0.176
Как указано в комментарии Джона Маховальда, между вашими удаленными серверами нет соглашения. Вот визуализация значений смещения и задержки:
Черные горизонтальные полосы - это расчетное время удаленного сервера, и они должен вокруг них есть несколько фиолетовых полос, показывающих возможные диапазоны значений времени, которые могут иметь ваши удаленные серверы. (Причина, по которой мы не видим их на этом графике, заключается в том, что вы находитесь в непосредственной близости к сети от ваших источников.) Эти диапазоны должны перекрываться, но этого не происходит в случае ваших источников.
Вот пример визуализации работающей настройки NTP:
Как вы можете видеть, во втором примере все центральные линии расположены близко друг к другу (и смещение близко к нулю), а также имеется большой диапазон перекрытия.
Итак, итог таков: ваши источники времени обслуживают неточное время, и NTP справедливо им не доверяет.
Недисциплинированные локальные часы (refid LOCL) использовать не следует. Убери это.
Недисциплинированные местные часы, как правило, больше не используются.
Первоначально он был разработан для использования, когда ntpd должен иметь возможность обслуживать время для других, даже если источники реального времени недоступны.
Недисциплинированные местные часы не резервное копирование экземпляра ntpd листового узла (т.е. только клиента).
Теоретически, если у NTP-сервера есть хороший генератор, он может обслуживать достаточно точное время без каких-либо других источников.
Он падает, потому что часы на большинстве компьютеров имеют низкую точность по сравнению с источниками, включая пул NTP. Однако LOCL имеет нулевую задержку, обычно низкая задержка означает небольшую ошибку. Таким образом, вероятные хорошие источники NTP, которые вы хотите использовать, выбрасываются алгоритмом пересечения, потому что ни один из них не близок к источнику с низкой задержкой. Вот только местные часы не точные ...
Смещение 460 мс - это дрейф в несколько дней для многих систем. Это могло быть меньше, но проблемы с выбором возникли, когда был введен LOCL. Кроме того, требуется много часов, чтобы дисциплинировать большое смещение без шага.
После того, как вы удалили LOCL, у вас останутся выбросы по алгоритму пересечения.
Несмотря на все использование refid clock.nyc.he.net, и все они находятся на расстоянии 0,2 мс, ваши серверы NTP по-прежнему смещены друг от друга максимум на 400 мс. Это ужасная производительность, много стандартных отклонений при ожидаемой ошибке.
Скользящий перезапуск службы ntp на ваших серверах. Или иным образом форсируйте ступенчатую коррекцию.
Также выясните, на чем размещены ваши NTP-серверы. Они должны быть слегка загружены, работать очень мало, но ntpd (или chronyd). Виртуальные машины приемлемы, но необходимо убедиться, что физические хосты синхронизируются с одной службой времени. Поскольку синхронизация времени хоста важна.