Почему NTP синхронизируется с ЛОКАЛЬНЫМ, а не с удаленным сервером?
Итак, я пытаюсь отладить мою текущую настройку 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), и мне нужны клиенты, чтобы получать время с сервера. Сейчас удаление "локального" сервера из файлов конфигурации клиента - единственный вариант, но я хотел бы понять, почему это происходит, и, если это вообще возможно, избегать изменения их конфигураций (изменение конфигурации будет большой работой из-за наше окружение...).
Кроме того, это выглядит как еще один дубликат без хорошего ответа.
6 ответов
Если настроен только один NTP-сервер, алгоритм не совсем уверен, кому доверять. Несмотря на то, что страта ниже с удаленным хостом, я уверен, что алгоритм думает, что местное время более надежно.
Попробуйте использовать prefer ключевое слово с вашим server заявление, чтобы установить это в качестве льготного источника времени.
РЕДАКТИРОВАТЬ -
Итак, похоже, что это дубликат этого вопроса, но я не чувствую, что у автора есть достаточный ответ, поэтому я все же хотел бы знать, почему местное время предпочитается серверу.
Для по-настоящему достаточного ответа вы будете копаться в недрах очень сложного алгоритма. Документация даже не становится слишком конкретной, но я уверен, что там есть официальный документ или спецификация.
Если я удаляю все "локальные" строки в конфигурации, поскольку ответ на другой вопрос подсказывает, что произойдет, если сервер недоступен? NTP умирает или он просто продолжает пытаться?
Демон NTP не умирает и не останавливается, но завершает синхронизацию после того, как ему не удается достичь удаленного сервера. Вот почему лучшие практики будут предлагать минимум три удаленных сервера и не использовать LCL, если вы не отключены от сети. Предлагаются три сервера, потому что, когда есть только два, и они не согласны, какой он выберет? Третий сервер должен помочь алгоритму устранить фиктивный сервер.
Наконец, я только что заметил, что вы не определяете driftfile, Это может помочь?
Мне кажется, что интервал смещения (разница между вашим системным временем и временем хоста 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
У вас не должно быть проблем после этого.
Я знаю, что это старо, но я думаю, что вы правы. Никто не показывает способ отладки проблем с ntpd. Оказывается, это выполнимо.
Я думаю, что вы были на правильном пути, когда вы подозревали, что использование LOCAL(0) локально и на вышестоящем сервере может быть проблемой.
Это определенно было на острове времени из 4 серверов, с которым у меня была похожая проблема. Все они были настроены быть равными друг другу, так что, возможно, это другая проблема для вас.
Во-первых, есть лучший способ обработки островов времени, который называется "сиротский режим" и поддерживается версиями ntpd последних нескольких лет:
Сиротский режим на doc.ntp.org
Первоначально все 4 сервера имели одинаковый уровень 10 и предпочитали свои локальные часы. Я исправил это, и тем не менее они предпочли свои локальные часы (хотя слой действительно важен).
Я использовал команду ntpq pe (peer), as, rv, чтобы понять, что происходит. Вам нужно использовать rv (readvar) в номере ассоциации для сервера, чтобы вывести информацию. pe и as, похоже, отсортированы по одному и тому же индексу, так что вы можете получить число как так. as имеет поле под названием условие, которое может показывать отклонение значения, если оно не нравится серверу.
В выводе rv есть поле, называемое flash. Если все хорошо, это будет ноль. Если нет, то это битовая маска (отображается в шестнадцатеричном формате) проблем. Их можно посмотреть здесь:
У меня была проблема 0800 peer_loop. Оказалось, что ремонт часов важен. При просмотре LOCAL(0) как на локальных часах, так и на удаленном сервере, ntpd подумал, что есть цикл. Дэвид Миллс подтверждает, что в сообщениях на comp.protocols.time'Как избежать зацикливания в NTP' (я достиг своего лимита в 2 ссылки, извините!)
Использование аргумента refid для fudge для установки уникального refid не сработало - оно все равно отображается как LOCAL(0) у получателя.
То, что действительно работало, использовало уникальные номера экземпляров для локального драйвера. 127.127.1.[0-3]. Используйте один и тот же идентификатор как на сервере, так и на линии выдумки. Когда я делал это, серверы обычно синхронизировались с сервером самого низкого уровня, который обычно использовал свои локальные часы. Однако иногда он пытался использовать один из других серверов, который использовал его в качестве источника. Однако времена были синхронизированы и, кажется, остаются такими.
Возможно, слишком поздно, чтобы помочь, но я предлагаю это, чтобы показать, что NTP поддается логике и устранению неисправностей. Я потратил часы, пытаясь найти ответ методом проб и ошибок, а потом нашел документы.
Уровень 10.130.33.201 в качестве LOCAL-сервера равен 9, что делает локальный уровень, рассчитанный из этого (9+1=10), конкурирующим с локальным LOCAL-сервером на уровне 10. Поскольку локальный LOCAL-уровень не имеет сетевых задержек или дрожания, он может выглядеть немного лучше для ntpd, чем удаленный.
Если вы хотите, чтобы эта конфигурация работала, установите для "главного" локального сервера уровень, равный 9. Не слишком низкий, если вы хотите, чтобы время, прослеживаемое для сервера уровня 1, было предпочтительным.
В исходном сценарии «сервер» находился на уровне 9 и тоже синхронизировался с . Как сказано в /questions/40984/pochemu-ntp-sinhroniziruetsya-s-lokalnyim-a-ne-s-udalennyim-serverom/40993#40993 , удаленный сервер уровня 9 локально будет уровнем 10, поэтому у него будет тот же уровень, что и у «локального» сервера.LOCAL", но с худшей статистикой. Поэтому будет использован локальный запасной вариант.
Обычно вам нужно как минимум четыре реальных NTP-сервера, а не только один, получающий время от ненадежных часов (ЛОКАЛЬНЫЙ). В интрасети вы можете захотеть распределить время с одного сервера и «уменьшить» (уменьшить слой) слой ЛОКАЛЬНОГО, если вы не можете позволить себе опорные часы с использованием GPS или (в Европе) DCF-77.
Используйте iburst, чтобы заставить сервер отправлять запрос NTP нужному NTS, даже если один запрос не удался