Почему NTP синхронизируется с ЛОКАЛЬНЫМ, а не с удаленным сервером?

11

Итак, я пытаюсь отладить мою текущую настройку NTP, и обнаружил, что смещение от моего единственного настроенного сервера составляет более 3 секунд, а не регулировка. Звездочка на LOCAL (0) в выводе ntpq, похоже, указывает на то, что система успешно синхронизируется с собой, а не с сервером 10.130.33.201 (который является еще одним linux-боксом в нашей системе, с которым мы хотим, чтобы все синхронизировалось).

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

И это мой файл ntp.conf. Написано кем-то другим, поэтому я не уверен на 100%, что все правильно.

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

Я читал о взрывах, iburst и minpoll / maxpoll, поэтому я понимаю, что они могут и не понадобиться, но я не думаю, что это как-то связано с моей текущей проблемой.

Кроме того, из-за того, как он развернут, для изменения этого конфигурационного файла потребуется много работы, поэтому я надеюсь, что на самом деле ничего не нужно менять. Я надеюсь, что это тот случай, когда я не понимаю, как работает NTP.


РЕДАКТИРОВАТЬ -

Итак, похоже, что это дубликат этого вопроса , но я не чувствую, что у автора есть достаточный ответ, поэтому я все же хотел бы знать, почему местное время предпочитается серверу. Кроме того, согласно одному из ответов ниже, я попытался использовать preferключевое слово в строке сервера конфигурации и перезапустить, но это, похоже, не дало эффекта.

Если я уберу все «локальные» строки в конфигурации, поскольку ответ на другой вопрос подсказывает, что произойдет, если сервер недоступен? NTP умирает или он просто продолжает пытаться?


ВАЖНОЕ РЕДАКТИРОВАНИЕ -

Хорошо, обычно 10.130.33.201 («сервер») не имеет доступа к Интернету и не имеет источника времени GPS для использования. Важным моментом является то, что все устройства в системе имеют одинаковое время с сервером, независимо от того, насколько корректным является это время.

Итак, просто чтобы посмотреть, что произойдет, я добавил один из серверов пулов NTP в конфигурационный файл сервера, чтобы он получал время оттуда, а не от локального. Теперь он правильно получает время с сервера времени NTP.

После этого клиенты теперь синхронизируются с сервером, а не предпочитают LOCAL (0).

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

НОВЫЙ ВОПРОС - Когда мой сервер использует локальный (оригинальный пример, который был дан), кажется, что клиенты говорят: «О, 10.130.33.201 использует LOCAL (0). Хм, у меня также есть LOCAL (0) сервер - - Я просто буду использовать это напрямую, а не получать ту же информацию через 10.130.33.201 ".

Это тот случай? Они пытаются перейти "прямо к источнику", который неверно ЛОКАЛЬНЫЙ (0)? Мне нужен мой сервер, чтобы получать время от LOCAL (0), и мне нужны клиенты, чтобы получать время с сервера. Сейчас удаление «локального» сервера из файлов конфигурации клиента - единственный вариант, но я хотел бы понять, почему это происходит, и, если это вообще возможно, избегать изменения их конфигураций (изменение конфигурации будет большой работой из-за наше окружение...).

Кроме того, это выглядит как еще один дубликат без хорошего ответа.

JPhi1618
источник
Кроме того, если у вас есть постоянный доступ к сети 10.130.33.201, рассмотрите возможность удаления локального источника синхронизации.
Аарон Копли

Ответы:

9

Если настроен только один NTP-сервер, алгоритм не совсем уверен, кому доверять. Несмотря на то, что страта ниже с удаленным хостом, я уверен, что алгоритм считает, что местное время более надежно.

Попробуйте использовать preferключевое слово в своем serverзаявлении, чтобы установить его в качестве источника предпочтительного времени.


РЕДАКТИРОВАТЬ -

Итак, похоже, что это дубликат этого вопроса, но я не чувствую, что у автора есть достаточный ответ, поэтому я все же хотел бы знать, почему местное время предпочитается серверу.

Для действительно достаточного ответа вы будете копаться в недрах очень сложного алгоритма. Документация даже не становится слишком конкретной, но я уверен, что там есть официальный документ или спецификация.

Если я уберу все «локальные» строки в конфигурации, поскольку ответ на другой вопрос подсказывает, что произойдет, если сервер недоступен? NTP умирает или он просто продолжает пытаться?

Демон NTP не умирает и не останавливается, но завершает синхронизацию после того, как ему не удается достичь удаленного сервера. Вот почему лучшие практики предложат минимум три удаленных сервера и не использовать LCL, если вы не отключены от сети. Предлагаются три сервера, потому что, когда есть только два, и они не согласны, какой он выберет? Третий сервер должен помочь алгоритму устранить фиктивный сервер.

Наконец, я просто заметил, что вы не определяете driftfile. Это может помочь?

Аарон Копли
источник
Влияет ли на это разница между двумя слоями? Поможет ли сервер ниже 9?
JPhi1618
Это может. По общему признанию, я не знаю много о внутренностях самого алгоритма. Тем не менее, единственный случай, когда вы должны выдумать слой, с местными часами. Я не могу рекомендовать вам выдумать удаленный сервер в качестве исправления. NTP следует доверять для определения наилучшего источника с минимальными помехами. У вас просто случается случай, когда вам нужно немного подтолкнуть его.
Аарон Копли
Спасибо за предложения. Был дрифт-файл, но он не создавался, поэтому я удалился, чтобы посмотреть, что произойдет. Удаление локальной линии делает синхронизацию с сервером, так что это что-то. Вы говорите, что ntpd «прекратит синхронизацию после того, как не достигнет удаленного сервера», но запустится ли он снова после достижения сервера? Я просто хочу быть в безопасности в случае временного прерывания сети.
JPhi1618
Нет, это не начнется снова. Это просто сдается. Это раздражает, и для меня это тоже подвох. Теперь мы знаем, чтобы перезапустить NTP, если сетевое соединение было потеряно. Вероятно, ваш дрифт-файл не создается, поскольку у ntp нет прав доступа к пути. Еще раз проверьте это.
Аарон Копли
7

Мне кажется, что интервал смещения (разница между вашим системным временем и временем хоста NTP) слишком сильно отличается для NTP, чтобы правильно установить его.

Мое предложение,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

У вас не должно быть проблем после этого.

Якорь,
источник
2
Если машина является виртуальной машиной или имеет какое-либо другое условие, которое заставляет ее работать с серьезно нарушенным временем, вы можете установить tinker panic 0опцию ntp, чтобы заставить NTP принимать любые смещения. Но используйте это только с NTP-серверами, которые наверняка никогда не вернут плохое время.
Zoredache
Хорошо, я думал, что это должно быть больше 1000 секунд, прежде чем это было проблемой, а затем я подумал, что сервер будет указан со знаком #? Разве это не так? Это «смещение» в секундах или миллисекундах?
JPhi1618
Он не будет синхронизироваться с 10.130.33.201 прямо сейчас, потому что смещение слишком велико, но это не исправит тот факт, что он в первую очередь дрейфует, что LCL становится более желательным. Я думаю, что это, работающий дрифт-файл, и preferсделает свое дело.
Аарон Копли
Не могли бы вы объяснить, почему смещение слишком велико? Это меньше 1000 (намного меньше) и знака # нет. Кроме того, я проверил фактическое время в обеих системах, и они находятся на расстоянии около 4 секунд.
JPhi1618
+/- 1000 мс ... не +/- 1000 с . Это в -3742 мс .
Аарон Копли
2

Уровень 10.130.33.201 в качестве LOCAL-сервера равен 9, что делает локальный уровень, рассчитанный из этого (9 + 1 = 10), конкурирующим с локальным LOCAL-сервером на уровне 10. Поскольку локальный LOCAL-уровень не имеет сетевых задержек или дрожания, он может выглядеть немного лучше для ntpd, чем удаленный.

Если вы хотите, чтобы эта конфигурация работала, установите для основного сервера LOCAL уровень ниже 9. Не слишком низкий, если вы хотите, чтобы время, прослеживаемое до уровня 1, было предпочтительным.

Коос ван ден Хаут
источник
Благодарю. Я проверю это, как только смогу. Выглядит многообещающе.
JPhi1618
Похоже, я ранее пытался снизить уровень локального сервера 10.130.33.201. В настоящее время он установлен на 5, клиент видит его как 6, но все еще предпочитает свой собственный LOCAL, который имеет уровень 10. Эта конфигурация была в наличии в течение нескольких дней.
JPhi1618
2

Я знаю, что это старо, но я думаю, что вы правы. Никто не показывает способ отладки проблем с ntpd. Оказывается, это выполнимо.

Я думаю, что вы были на правильном пути, когда вы подозревали, что использование LOCAL (0) локально и на вышестоящем сервере может быть проблемой.

Это определенно было на острове времени из 4 серверов, с которым у меня была похожая проблема. Все они были настроены быть равными друг другу, так что, возможно, это была другая проблема для вас.

Однако, во-первых, есть лучший способ обработки островов времени, называемый бесхозным режимом, который поддерживается версиями ntpd последних нескольких лет:

Сиротский режим на doc.ntp.org

Первоначально все 4 сервера имели одинаковый уровень 10 и предпочитали свои локальные часы. Я исправил это, и все же они предпочли свои локальные часы (хотя слой действительно важен).

Я использовал команду ntpq pe (peer), as, rv, чтобы понять, что происходит. Вам нужно использовать rv (readvar) в номере ассоциации для сервера, чтобы вывести информацию. pe и as, похоже, отсортированы по одному и тому же индексу, так что вы можете получить таким же образом число. as имеет поле с именем condition, которое может показывать отклонение значения, если оно не нравится серверу.

В выводе rv есть поле, называемое flash. Если все хорошо, это будет ноль. Если нет, то это битовая маска (отображается в шестнадцатеричном формате) проблем. Их можно посмотреть здесь:

ntpd внутренние декодеры

У меня была проблема 0800 peer_loop. Оказалось, что ремонт часов важен. При просмотре LOCAL (0) как на локальных часах, так и на удаленном сервере, ntpd подумал, что есть цикл. Дэвид Миллс подтверждает, что в сообщениях на comp.protocols.time 'Как избежать зацикливания в NTP' (я достиг своего лимита в 2 ссылки, извините!)

Использование аргумента refid для fudge для установки уникального refid не сработало - оно все равно отображается как LOCAL (0) у получателя.

То, что действительно работало, использовало уникальные номера экземпляров для локального драйвера. 127.127.1. [0-3]. Используйте один и тот же идентификатор как на сервере, так и на линии выдумки. Когда я делал это, серверы обычно синхронизировались с сервером самого низкого уровня, который обычно использовал свои локальные часы. Однако иногда он пытался использовать один из других серверов, который использовал его в качестве источника. Однако времена были синхронизированы и, похоже, остались такими.

Возможно, слишком поздно, чтобы помочь, но я предлагаю это, чтобы показать, что NTP поддается логике и устранению неполадок. Я потратил часы, пытаясь найти ответ методом проб и ошибок, а потом нашел документы.

klw14
источник
-1

Используйте iburst, чтобы заставить сервер отправлять запрос NTP нужному NTS даже в случае сбоя одного запроса.

Tempteh
источник
Это нужно лучшее объяснение.
Свен