У меня есть две Linux-машины (A и B) в изолированной сети. Они должны быть синхронизированы по времени. Машина A получает питание с перерывами и должна обслуживать время, поскольку она подключена к авторитетному источнику времени (GPS). Машина B получает питание только в том случае, если питание машины A, но это встроенное устройство Linux, и его состояние питания будет часто меняться. Ни одна из машин не имеет доступа к другим системам. Это закрытая сеть.
Я понимаю, что это довольно сложная задача для NTP, поскольку NTP обычно ожидает контакта с несколькими серверами. У меня проблемы с тем, чтобы это работало должным образом на машине B. Машина A синхронизируется с GPS очень хорошо, и машина B может связаться с машиной A и даже выполнять запросы времени, но машине A не доверяют (возможно, самой по себе?). После целого часа работы машины А это внезапно изменилось, и машина Б заработала. Однако, когда машина A вышла из строя (и, следовательно, машина B), машина B снова не может найти подходящую синхронизацию времени.
Вот некоторая информация о ntpdate. Обратите внимание, что даже когда уровень машины A равен 1, операция завершается ошибкой с тем же выходом в конце.
10.10.10.1: Server dropped: strata too high
server 10.10.10.1, port 123
stratum 16, precision -19, leap 11, trust 000
refid [10.10.10.1], delay 0.02614, dispersion 0.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 6:28:16.000
originate timestamp: d3a9bdc4.27ebb350 Thu, Jul 12 2012 21:19:00.155
transmit timestamp: bc17c803.b42dfffe Sat, Jan 1 2000 0:25:39.703
filter delay: 0.02625 0.02614 0.02618 0.02625
0.00000 0.00000 0.00000 0.00000
filter offset: 39544160 39544160 39544160 39544160
0.000000 0.000000 0.000000 0.000000
delay 0.02614, dispersion 0.00000
offset 395441600.451568
1 Jan 00:25:39 ntpdate[677]: no server suitable for synchronization found
Я предполагаю, что машина А просто не доверяет себе в части отсчета времени. После 51 минуты (может быть, раньше, я не знаю) времени безотказной работы и синхронизации часов с GPS, машина A начала правильно отсчитывать время, а машина B. Мне нужно, чтобы это случилось раньше. Если возможно, в течение нескольких секунд.
Со следующими конфигурациями (и долгим ожиданием) в конечном итоге это удается.
Машинный файл ntp.conf:
server 127.127.28.0 prefer true minpoll 4 maxpoll 4 fudge 127.127.28.0 stratum 1 time1 0.420 refid GPS
Машина B ntp.conf:
server 10.10.10.1 prefer true minpoll 4 maxpoll 4
ntpq -c сверстники на машине B без своевременного исправления:
remote refid st t when poll reach delay offset jitter ============================================================================== 10.10.10.1 .STEP. 16 u 9 16 0 0.000 0.000 0.000
ntp1 -c сверстники на машине B с своевременным исправлением:
remote refid st t when poll reach delay offset jitter ============================================================================== *10.10.10.1 SHM(0) 2 u 7 16 17 0.669 2.597 1.808
Итак, теперь возникает вопрос: как мне быстро заставить машину А довериться?
Некоторые отладочные данные с машины A до и после того, как машина B решит, что машина A достаточно хороша для использования.
перед..
~ # ntpq -c rv associd=0 status=c418 leap_alarm, sync_uhf_radio, 1 event, no_sys_peer, version="ntpd 4.2.6p4@1.2324 Fri Feb 24 15:01:45 UTC 2012 (1)", processor="armv7l", system="Linux/2.6.35.14", leap=11, stratum=2, precision=-19, rootdelay=0.000, rootdisp=44.537, refid=SHM(0), reftime=d3ab0053.43b44780 Fri, Jul 13 2012 20:15:15.264, clock=d3ab0062.e7e03154 Fri, Jul 13 2012 20:15:30.905, peer=34819, tc=4, mintc=3, offset=0.000, frequency=0.000, sys_jitter=3.853, clk_jitter=36.492, clk_wander=0.000
после...
~ # ntpq -c rv associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, version="ntpd 4.2.6p4@1.2324 Fri Feb 24 15:01:45 UTC 2012 (1)", processor="armv7l", system="Linux/2.6.35.14", leap=00, stratum=2, precision=-19, rootdelay=0.000, rootdisp=41.278, refid=SHM(0), reftime=d3ab0063.43b37856 Fri, Jul 13 2012 20:15:31.264, clock=d3ab006d.9ee53ec2 Fri, Jul 13 2012 20:15:41.620, peer=34819, tc=4, mintc=3, offset=0.000, frequency=43.896, sys_jitter=0.762, clk_jitter=36.953, clk_wander=0.000
NTP должен работать нормально. Посмотрите на некоторые варианты быстрой синхронизации при запуске. Посмотрите на burst и iburst варианты для системы Б. Посмотрите на true опция для источника часов GPS.
Рассмотрите возможность использования аппаратных часов в качестве резервного источника времени в обеих системах. Установите систему более высокого уровня B. Должно работать примерно следующее:
server 127.127.1.0
fudge 127.127.1.0 stratum 8
Следите за выходом ntpq -c peers чтобы увидеть, когда вы получите надежный источник часов. Как обычно ntp хочет получить несколько ответов от надежного источника времени, прежде чем он ему доверяет. На это указывает первый символ в каждой строке.
Хотя NTP любит больше источников, любое нечетное количество источников времени на одном уровне страты должно работать хорошо. Поскольку у вас есть только два сервера и часы GPS, приоритет (слой) источников должен увеличиваться от GPS, часов на сервере A, часов на сервере B. Увеличение страты между каждым из них на три или четыре уровня обеспечит соблюдение приоритетов.
РЕДАКТИРОВАТЬ: Если у вас есть NTP-сервер busybox на сервере A, возможно, стоит установить полный пакет сервера ntp. Понимание того, что происходит с сервером A, должно иметь большое значение для решения вашей проблемы. Вам понадобится хотя бы один надежный источник времени, прежде чем сервер B сможет ему доверять. Если ntpq -c peers не работает, тогда вы можете попробовать ntpdc peers. Обе эти команды позволяют запрашивать другие хосты. А peerstats log также может быть полезен.
На сервере B используйте ntpclient, как описано в документации. Busybox NTP как записывать, что на нем происходит
Часы должны быть достаточно близки к правильному времени, если серверы не простаивали долгое время. Если вам нужно синхронизировать две системы, этого должно быть достаточно. В конечном итоге GPS синхронизирует время с реальным миром.
'ntpd -q' синхронизируется быстро, но завершается (поведение ntpdate). За ним должен следовать ntpd без опции выхода для непрерывной синхронизации.
EDIT2: я проверяю свой сервер и обнаружил, что один из серверов отключился на секунду. Исправляя это, я играл с настройками. iburst очень быстро доверяет серверу. true гарантирует, что драйверу часов можно доверять, если не было нескольких других доверенных источников. Часы заняли чуть больше минуты, прежде чем им стало доверять локально и им можно было доверять удаленно.
Во время тестирования вы сможете перезапустить ntpd выполните процесс после синхронизации и проверьте, насколько быстро работают настройки. В приведенном выше случае может потребоваться перезапуск сервера B, чтобы проверить, насколько быстро он синхронизируется. При мониторинге ntpd изменения я использую такую строку:
while ntpq -c peers localhost; do sleep 10; done
Имя хоста и время сна настраиваются по мере необходимости. В некоторых случаях я связываю два или более ntpq командные строки в цикле. При этом я использую команду echo и / или date, чтобы указать, где меняются наборы данных.