Я пробовал несколько руководств по настройке локального ntp-сервера в ubuntu, но ни одно из них не работает правильно. Мои серверы по какой-то причине сильно дрейфуют во времени, и я должен держать их время близко друг к другу, потому что я запускаю базы данных, которые этого требуют.
В настоящее время мой сервер (ip. 24) запускает этот /etc/ntp.conf:
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
# Give localhost full access rights
restrict 127.0.0.1
# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap
broadcast 192.168.178.0
А по «клиентам»:
# Point to our network's master time server
server 192.168.178.24 iburst
fudge 192.168.178.24 stratum 10
restrict default ignore
restrict ::1
restrict 127.0.0.1
restrict 192.168.178.24 mask 255.255.255.255 nomodify notrap noquery
driftfile /var/lib/ntp/drift
minpoll 4
maxpoll 5
Примечание: я использовал Multi-Tabbed Putty для отправки следующих команд всем клиентам ntp одновременно. Я остановил службы ntp для всех, кроме сервера, используемого sudo ntpdate 192.168.178.24 чтобы позволить им получить дату и после этого перезапустить службы ntp. Это удалось. Все серверы показывали одну и ту же дату сразу после завершения команды. Однако примерно через 10 минут мои серверы показывают следующее время:
Fr 30. Sep 11:16:53 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016 (server .24)
Fr 30. Sep 11:16:50 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:17:05 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Как правильно синхронизировать их с ntp-сервером? А как уменьшить время опроса? Похоже, мои серверы быстро перестают синхронизироваться, поэтому мне нужно, чтобы они снова получили "правильное" время ...
Под «правильным» временем я подразумеваю время, одинаковое для всех серверов. Это не обязательно должно быть точным и правильным мировым временем (если вы его так называете).
Изменить: я пробовал предлагаемую настройку конфигурации. Насколько я понял, именно так должны выглядеть мои конфиги сервер / клиент. Между тем, я заметил, что мой сервер .24 на самом деле дрейфует в худшее время. Сервер .20 является наиболее точным, и сейчас я использую сервер .20 для размещения сервера NTP. Извините за путаницу.
Конфигурация сервера:
# Use the local clock
server 127.127.1.0 prefer
fudge 127.127.1.0
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
# Give localhost full access rights
restrict default
# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap
broadcast 192.168.178.0
Для клиентов:
# Point to our network's master time server
server 192.168.178.20 iburst
restrict default
driftfile /var/lib/ntp/drift
minpoll 4
maxpoll 5
ntpq -as и ntpq -pe на сервере:
ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 41906 963a yes yes none sys.peer sys_peer 3
2 41907 8811 yes none none reject mobilize 1
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 5 l 60 64 377 0.000 0.000 0.000
192.168.178.0 .BCST. 16 u - 64 0 0.000 0.000 0.000
В пять раз похожий результат (эти серверы дрейфуют во времени):
ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 62104 9024 yes yes none reject reachable 2
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
hadoop20.xx LOCAL(0) 6 u 27 64 377 0.151 63591.8 33407.0
Для двух (скорее всего?) Работающих клиентов:
ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 7757 963a yes yes none sys.peer sys_peer 3
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
*hadoop20.xx LOCAL(0) 6 u 18 64 377 0.183 7.883 3.015
редактировать 2:
я использовал sudo service ntp stop, sudo ntpdate 192.168.178.20, дождитесь завершения работы ntpdate, sudo service ntp start по всем клиентам. Осталось только 2 преуспевающих клиента и 5 отвергающих клиентов.
Отклоняющие клиенты показывают этот вывод. В delay + offset значения выглядят высокими, потому что отказавшие клиенты дрейфуют во времени. Может быть, они не доверяют серверу обновлять время, потому что задержка / смещение слишком велики?
ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 20981 905a yes yes none reject sys_peer 5
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
hadoop20.xx LOCAL(0) 6 u 34 64 3 0.166 18665.9 16201.3
Я тоже пробовал использовать это https://askubuntu.com/a/256004 ответ, он работает около 30 секунд, затем состояние снова меняется на "отклонить"! То же самое для ntpdate -s 192.168.178.20. Скорее всего, это связано с тем, что клиенты ntp отклоняют время сервера. Есть ли способ заставить их изменить время?
Не делай этого. Шутки в сторону. Только не надо. Люди продолжают придумывать идею, что NTP разработан, чтобы позволить группе машин иметь тем же время. Это не так. Он разработан довольно тщательно, чтобы позволить многим машинам иметь все самое близкое к верный время, что не одно и то же.
Если у вас есть доступ к окну, вы можете создать наполовину приличный сервер уровня 1 примерно за 50 фунтов стерлингов или за 100 фунтов стерлингов. Вам будет гораздо лучше создать что-то подобное, а затем указать на это другим клиентам. Правильные временные метки намного лучше, чем просто самосогласованные, не в последнюю очередь для судебной экспертизы.
Но если вы обязательно должны делать то, что делаете, тогда вам нужно понять, что вы извращаете ntpd, и это будет означать понимание что ты делаешь.
На сервере
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 10
средства "использовать местные недисциплинированные часы, как если бы они были авторитетными", что вы и хотите. Я не уверен, почему вы заставляете его использовать уровень 10; подумайте о том, чтобы отказаться от stratum 10, и пусть драйвер предоставит свой уровень по умолчанию, равный 0. На клиентах
server 192.168.178.24 iburst
fudge 192.168.178.24 stratum 10
вообще не имеет смысла. fudge 127.127.x.y зарезервирован для принудительного использования различных видов локальных драйверов часов. Нет смысла давать ему другой адрес. Отбросьте fudge линия от клиентов и просто укажите их на сервере. Вы также используете закрытую сеть, поэтому откажитесь от всех мер безопасности, пока она не заработает:
restrict default
Если это все еще не работает, нам нужно увидеть результат ntpq -c as и ntpq -c pe как на сервере, так и на клиенте, который плохо себя ведет, после как минимум десяти минут непрерывной работы.
редактировать: вы пишете в комментарии под этим "Я думаю, что смещение / дрожание действительно велико, потому что сбойные клиенты дрейфуют во времени".
Думаю, ты прав. Блог этого парня предполагает, что у него был тот же опыт: часы клиента были настолько плохими, что обманули местные ntpd думать, что сервер ненадежен. Он написал
наконец, причина огромного дрожания кажется ясной! Наши часы дрейфуют так быстро, что смещение увеличится на несколько секунд после наших нескольких измерений.
Учитывая, что именно ваши клиенты, время которых уходит быстрее всего, не могут синхронизироваться (помечая сервер как «отклоненный»), я думаю, вы наблюдаете тот же эффект. Его решением было использовать adjtimex чтобы вручную настроить часы ядра (настройка tick value) до тех пор, пока системные часы не станут менее сбивчивыми, и в этот момент ntpd сможет распознать сервер как исправный и синхронизироваться с ним. Вероятно, вам стоит сначала попробовать это на худшем клиенте и посмотреть, поможет ли это.
Вы можете полностью отказаться от NTP, вручную установить время на «сервере» и выполнить эту команду:
ssh root@192.168.178.xxx "date -s \"$(date "+%F %T")\""
Прокрутите его через все свои "клиентские" IP-адреса, и готово!
Пояснение: местное время будет "скопировано" на удаленную машину по SSH.