Мы развертываем серверы Ubuntu 14.04 в изолированных сетях, на которых запущен ntpd 4.2.6p5, настроенный на использование нескольких серверов NTP, предоставленных клиентами (без доступа к pool.ntp.org). Наши немые терминальные клиентские устройства работают под управлением старой версии BusyBox (1.00-rc2) и ntpclient 2010 от Ларри Дулиттла.
Эта установка отлично работает в течение многих лет, но недавно мы столкнулись с препятствием с новым клиентом. Они предоставили нам 5 внутренних адресов NTP-серверов, которые, кажется, отлично работают сами по себе, насколько это возможно. ntpdate-debian касается сервера Linux. Однако на стороне BusyBox ntpclient жалуется на "Слишком высокая дисперсия". Из вывода отладки, ntpclient получает «1217163.1» от сервера NTP, но максимальное поддерживаемое значение является абсолютным (65536).
$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
-c probe_count 1
-d (debug) 1
-g goodness 0
-h hostname 10.17.162.250
-i interval 15
-l live 0
-p local_port 0
-q min_delay 800.000000
-s set_clock 1
-x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0 VN=3 Mode=4 Stratum=4 Poll=4 Precision=-20
Delay=60745.2 Dispersion=1346801.8 Refid=10.31.10.21
Reference 3668859928.942079
(sent) 3668859928.708371
Originate 3668859928.708371
Receive 3668859928.963271
Transmit 3668859928.963369
Our recv 3668859928.708371
Total elapsed: 0.00
Server stall: 93.09
Slop: -93.09
Skew: 255443.94
Frequency: 0
day second elapsed stall skew dispersion freq
42463 56728.708 rejected packet: abs(DISP)>65536
Все эти устройства находятся в одной локальной сети, поэтому, честно говоря, я ошеломлен. Даже в ужасе.
Вот ntpq -pn вывод с сервера Ubuntu 14.04:
user@host:~$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 1025 64 0 0.000 0.000 0.000
10.17.162.249 10.17.6.10 5 u 23 1024 37 0.865 1381.07 697.260
10.31.10.22 .LOCL. 1 u 1044 1024 17 29.586 -838.06 397.342
10.17.6.10 10.31.10.21 4 u 1065 1024 17 0.366 105.245 402.999
*10.31.10.21 132.246.11.238 3 u 5 1024 37 29.418 794.292 616.796
10.17.6.11 10.31.10.21 4 u 1038 1024 17 0.408 120.030 381.058
Мои вопросы:
ntp.conf? На самом деле ничего особенного там нет.Я вижу некоторую путаницу в ответах здесь. Для начинающих, ntpclient, по крайней мере, в -s режим, не действует как полноценный клиент NTP, он только отправляет и принимает один пакет, поэтому нет "последних 8 полученных пакетов". На самом деле он вообще не оценивает собственную дисперсию.
Вместо этого значение, которое он печатает, представляет собой значение, называемое «корневой дисперсией» (rootdisp) в пакете, возвращаемом сервером, которое является оценкой общего количества ошибок / расхождений между этим сервером и правильным временем. Это вычисляется довольно просто: каждый NTP-сервер получает время либо от внешних часов (например, радио или GPS-приемника), либо от другого NTP-сервера. Если сервер получает свое время от внешних часов, его корневая дисперсия является расчетной максимальной ошибкой этих часов. Если он получает свое время от другого сервера NTP, его корневая дисперсия - это корневая дисперсия этого сервера. плюс рассеяние, добавленное сетевым соединением между ними.
Единственное замешательство здесь заключается в том, что, хотя ntpq и chrony отображают дисперсию и корневую дисперсию в секундах, на что люди привыкли смотреть, ntpclient отображает это в микросекунды. Тем не менее, значение 1217163 все еще довольно велико. Хороший NTP-сервер знает время за несколько миллисекунд; плохой в течение нескольких десятков или сотен миллисекунд. Ваш сообщает вам, что его времени можно доверять только с точностью до +/- 1,2 секунды.
Вы в любом случае можете заставить ntpclient синхронизироваться с этим сервером, передав -x 0 или -t опция (в зависимости от версии ntpclient), которая отключает проверки работоспособности NTP. Если вам нужно только приблизительное точное время (с точностью до нескольких секунд), этого может быть достаточно. Однако ntpclient довольно разумно отказывается синхронизироваться с таким плохим сервером. Ваш ntpq вывод на машине ubuntu показывает дрожание в сотни миллисекунд для всех его серверов, даже несмотря на то, что у них низкая задержка, что указывает либо на очень ненадежную сеть, либо на заговор все серверов, чтобы обеспечить нестабильное время или базовую проблему хронометража на самом сервере.
Меня также беспокоит, что сервер 10.31.10.22 рекламирует рефид LOCL (недисциплинированные местные часы), но имеют слой 1. Обычно локальные часы подделываются к слою из 10, так что они используются только в качестве источника синхронизации в крайнем случае, чтобы не дать стаду разойтись. Либо 10.31.10.22 неправильно настроен и предоставляет плохое время для остальной части сети, либо он дисциплинируется до хорошего времени какой-то программой вне контроля NTP, и в этом случае неправильная конфигурация просто заключается в том, что он рекламирует LOCL рефид; его следует переопределить, например, GPS или что бы там ни было.
Частичный ответ на вопрос «Что такое дисперсия?»:
Типичный обход NTP туда и обратно:
client | | server
t1 |------->| t2
t3 |<-------| t4
Это дает два значения: смещение (разница во времени между клиентом и сервером) и задержка (существенно время прохождения сети) по следующим формулам:
offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)
Клиент выбирает текущее смещение из последних 8 полученных пакетов, выбирая тот с наименьшей задержкой.
Те же 8 пакетов используются для расчета разброс путем выполнения средневзвешенного значения разницы этих 8 смещений с выбранным на последнем этапе, где задержка используется в качестве весового коэффициента, придавая больший вес меньшим задержкам. Это мера «разброса» значений, используемая для расчета качества сервера времени, особенно если у вас есть несколько вариантов на выбор.
Ваша дисперсия и перекос огромны, есть очень большое смещение от локальных часов к этому узлу. Вы должны сравнить смещения с местными date и установите часы вручную.
Запустите ntpd и покажите ntpq -p от хоста с использованием всех пиров. Он выберет лучшие.
Согласно эта документация cisco, "разбросв секундах - это максимальная разница во времени, которая когда-либо наблюдалась между локальными часами и часами сервера ". С серверами ntp, которые не полностью сломаны, никогда не должно происходить сильного разброса. Единственный возможный сценарий - когда ваш клиент запускает ntp и пока доступны только его локальные часы. И даже тогда такая высокая дисперсия, как вы сообщаете, соответствует часам, которые отстают более чем на две недели.
Этого должно быть достаточно, чтобы убедиться, что локальные часы не слишком сильно отстают вначале (даже пара часов все еще будет приемлемой), либо путем настройки часов (и даже даты!) В BIOS, либо путем выдачи ntpdate один раз перед запуском ntpd на клиенте.