Я пытаюсь настроить NTP в локальной сети, в которой нет (и никогда не будет) подключения к Интернету. Главный приоритет заключается в том, что машины в сети синхронизируются друг с другом, даже если время, в которое они синхронизируются, не является точным на 100%.
У нас также есть требование использовать иерархию NTP для репликации настройки развернутой системы. Я хочу создать такую иерархию машин:
Moon (Main Server running Windows) (10.1.3.10)
|____Earth (Linux x64 client) (10.1.3.1)
|____Mars (Linux x64 client) (10.1.3.2)
|____Saturn (Linux x64 client) (10.1.3.3)
|____RackCard23 (Linux x64 client and server to the two machines below) (10.1.3.23)
|___RackCard21 (Linux x64 client) (10.1.4.21)
|___RackCard22 (Linux x64 client) (10.1.4.22)
Обратите внимание, что карты RackCard имеют два порта Ethernet, один из которых подключен к сети 10.1.3.x, а другой - к сети 10.1.4.x. RackCard23, который синхронизируется с главным сервером Moon, будет делать это в сети 10.1.3.x, а RackCard22 / 23 будет подключаться к RackCard23 в сети 10.1.4.x. Это потому, что я не хочу, чтобы RackCards22 / 23 покидали свою сеть, чтобы синхронизировать время, и потому, что он реплицирует окончательно развернутую систему.
Пока мне удалось получить все, что должно, синхронизируя с Moon для правильной синхронизации (включая RackCard23).
Но у меня возникают проблемы с синхронизацией RackCard22 и 23 с RackCard23.
[root@RackCard23]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"
server 10.1.3.10 iburst minpoll 4 maxpoll 4 prefer #This is what we want to happen
fudge 127.127.1.0 stratum 2 #Not sure about these two lines, was trying to force it to be a stratum 2 server
fudge 127.127.0.1 stratum 2
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift
restrict 10.1.3.10 mask 255.255.255.255 nomodify notrap noquery
#Attempt to get to act as an NTP Server
broadcast 10.1.4.255
restrict 10.1.3.21 mask 255.255.255.255 nomodify notrap
restrict 10.1.4.21 mask 255.255.255.255 nomodify notrap
Это результат ntptrace:
[rootRackCard23]# /usr/sbin/ntptrace
localhost.localdomain: stratum 16, offset 0.000000, synch distance 0.000030
Как видите, машина сообщает о себе как о сервере уровня 16, несмотря на то, что он был синхронизирован с сервером уровня 1 (Луна):
[root@RackCard23 awd]# /usr/sbin/ntpdate -d 10.1.3.10
21 Jun 13:55:09 ntpdate[19410]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.3.10 and service ntp
host found : 10.1.3.10
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
server 10.1.3.10, port 123
stratum 1, precision -6, leap 00, trust 000
refid [LOCL], delay 0.04135, dispersion 0.00383
transmitted 4, in filter 4
reference time: cfc99402.e010624d Mon, Jun 21 2010 8:32:18.875
originate timestamp: cfc9dfad.48000000 Mon, Jun 21 2010 13:55:09.281
transmit timestamp: cfc9dfad.47e27179 Mon, Jun 21 2010 13:55:09.280
filter delay: 0.04155 0.04155 0.04137 0.04135
0.00000 0.00000 0.00000 0.00000
filter offset: -0.01448 0.000781 0.000537 0.000394
0.000000 0.000000 0.000000 0.000000
delay 0.04135, dispersion 0.00383
offset 0.000394
21 Jun 13:55:09 ntpdate[19410]: adjust time server 10.1.3.10 offset 0.000394 sec
Конфигурация клиентов (RackCard21 / 22) выглядит так:
[root@RackCard21]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"
server 10.1.4.23 iburst minpoll 4 maxpoll 4 prefer
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift
# restrict 127.0.0.1
restrict None mask 255.255.255.255 nomodify notrap noquery
И ntptrace дает следующее:
[root@RackCard21]# /usr/sbin/ntpdate -d 10.1.4.23
21 Jun 14:04:34 ntpdate[14381]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.4.23 and service ntp
host found : 10.1.4.23
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
10.1.4.23: Server dropped: strata too high
server 10.1.4.23, port 123
stratum 16, precision -20, leap 11, trust 000
refid [10.1.4.23], delay 0.02568, dispersion 0.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 6:28:16.000
originate timestamp: cfc9dfef.12b79516 Mon, Jun 21 2010 13:56:15.073
transmit timestamp: cfc9e1e2.aeae7d56 Mon, Jun 21 2010 14:04:34.682
filter delay: 0.02573 0.02571 0.02568 0.02568
0.00000 0.00000 0.00000 0.00000
filter offset: -499.609 -499.609 -499.609 -499.609
0.000000 0.000000 0.000000 0.000000
delay 0.02568, dispersion 0.00000
offset -499.609286
21 Jun 14:04:34 ntpdate[14381]: no server suitable for synchronization found
Таким образом, он не может найти подходящий сервер, потому что сервер, который я пытаюсь использовать, сообщает, что это сервер уровня 16 (что, как я считаю, означает несинхронизированный). И это несмотря на то, что он синхронизирован.
Поэтому мне нужно как-то сделать RackCard23 более высоким слоем (в идеале - слоем 2). Как мне это сделать?
Любая помощь очень ценится, так как я уже несколько дней пытаюсь заставить это работать!
РЕДАКТИРОВАТЬ:
Привет, Кристофер,
Я перезагружал ntpd, да;)
Все Linux-боксы работают под управлением CentOS 5.4.
Это результат предложенных вами команд. Сначала с сервера:
[root@RackCard23]# /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.1.3.10 .INIT. 16 u - 16 0 0.000 0.000 0.000
10.1.4.255 .BCST. 16 u - 64 0 0.000 0.000 0.001
[root@RackCard23]# /usr/sbin/ntpdc -c monlist
remote address port local address count m ver code avgint lstint
===============================================================================
localhost.localdomain 34566 127.0.0.1 1 7 2 0 0 0
10.1.4.21 123 10.1.4.23 5 3 4 180 5 1
10.1.4.22 123 10.1.4.23 7 3 4 0 2 2
А потом от клиента:
[root@RackCard21]# /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.1.4.23 .INIT. 16 u 10 16 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 10 l 44 64 1 0.000 0.000 0.001
Как упоминал Крис, уровень 16 указывает, что сервер на самом деле не синхронизировался с сервером. На всякий случай, вы перезапустили службы ntp, верно? (service ntpd restart
) Я не пытаюсь внушить, что вы упускаете простые вещи, но я всегда так делаю!
Можете ли вы опубликовать вывод еще нескольких команд, чтобы помочь в диагностике?
ntpq -p
на клиенте и сервере. Должен показать, какие серверы он настроил, а также статистику для этих серверов.
ntpdc -c monlist
на сервере. Должен показать подключенных клиентов.
Кроме того, поскольку вы не упомянули ОС, я использую команды стиля RHEL. Дайте мне знать, если у вас есть что-то другое.
ИЗМЕНИТЬ после дополнительной информации
Хорошо, видя ваш результат, вот ваша проблема: у вас нет сервера уровня 1. Фактически, «Луна» использует свои местные часы. Он сообщает о себе как о сервере уровня 16. Для справки: на сервере Stratum1 будут локальные GPS или атомные часы. У тебя есть такой? В противном случае Moon необходимо синхронизировать свои часы с ДРУГОЙ ntp-сервером. Если у него нет доступа к сети, вам нужно обмануть его слой. (Это требует, чтобы вы не слишком заботились об «истинном» времени. Что вы не делаете, но все, кто читает это, должны это заметить.)
На Moon добавьте следующую строку в ваш файл ntp.conf: fudge 127.127.1.0 stratum 10
. Это заставит его сообщать о своих локальных часах как о страте 10. Что заставит все другие серверы использовать их по своим локальным часам слоя 16.
- Кристофер Карел
Может быть, не по теме, локальный сервер Stratum 2 требует подключения к серверу Stratum 1, а в вашей изолированной сети у вас его нет.
Вы можете получить дешевый модуль GPS и Raspberry Pi, одноплатный компьютер с минимальным энергопотреблением и широкими возможностями интерфейса. Подключите свой модуль GPS к Raspberry Pi и подключите Pi к своей сети, с соответствующим программным обеспечением, это может быть ваш NTP-сервер Stratum 1, который является вашим сервером Stratum 2, или, поскольку он находится в вашей сети, каждый компьютер синхронизирует время с.
NTPd установит свой собственный слой в соответствии с:
(Это не обязательно порядок событий, но порядок, в котором они обрабатываются с целью установки локальной страты.)
(Кроме того, уровень 16 не обязательно означает, что он несинхронизирован).
В качестве своего рода в стороне я включу некоторый анализ вашего вывода ntpq. Просто чтобы помочь в устранении общих неисправностей в будущем для себя и других.
Сначала с вашего сервера:
[root@RackCard23]# /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.1.3.10 .INIT. 16 u - 16 0 0.000 0.000 0.000
10.1.4.255 .BCST. 16 u - 64 0 0.000 0.000 0.001
В первом столбце указаны два сервера, с которыми этот компьютер настроен для синхронизации. Примечательно отсутствие *
или +
это указывало бы на синхронизированного партнера или вторичных кандидатов. Это означает, что ваш сервер не будет использовать записи здесь, но, по крайней мере, проверяет их.
В третьем столбце «st» указывается слой этих серверов. В данном случае это означает, что обе эти машины используют свои локальные часы. (страта по умолчанию - 16). Последние три столбца показывают, насколько далеко отстоят два часа. Либо в значении «секундной разницы в часах», либо в задержке между двумя машинами, в зависимости от разницы в этой задержке. Здесь чем больше, тем хуже.
Причина таких несинхронизированных записей может зависеть от некоторых факторов: если смещение в часах слишком велико, то ntp даже не будет пытаться, так как это приведет к слишком большому скачку в местном времени. Если джиттер становится слишком низким, клиент будет рассинхронизировать, пока все не стабилизируется. (Обычно это временно, но все же повторяется). В качестве альтернативы, как и в вашем случае, если настроенные серверы имеют равные или более высокие значения страты, что означает, что они менее надежны в качестве источников времени, тогда клиент не будет их использовать.
- Кристофер Карел