Один NTP-сервер в изолированной сети

У меня есть две машины Linux (A и B) в изолированной сети. Они должны быть синхронизированы по времени. Машина A получает питание периодически и должна обслуживать время, так как она подключена к авторитетному источнику времени (GPS). Машина B получает питание только в том случае, если машина A включена, но это встроенное устройство Linux, и ее состояние питания часто меняется. Ни одна из машин не имеет доступа к другим системам. Это закрытая сеть.

Я понимаю, что это довольно сложный заказ для NTP, так как NTP обычно ожидает контакта с несколькими серверами. У меня проблемы с настройкой правильной работы на компьютере B. Компьютер A прекрасно синхронизируется с GPS, и компьютер B может подключаться к компьютеру A и даже выполнять запросы времени, но компьютеру A не доверяют (возможно, он сам по себе?). После целого часа работы машины A это внезапно изменилось, и машина B заработала. Однако, когда машина A вышла из строя (и, следовательно, машина B), машина B снова не может найти хорошую синхронизацию времени.

Вот некоторая информация ntpdate. Обратите внимание, что даже когда страта аппарата А равна 1, операция завершается неудачно с тем же выходным сигналом в конце.

10.10.10.1: Сервер сброшен: слишком высокие уровни
сервер 10.10.10.1, порт 123
пласт 16, точность -19, скачок 11, доверие 000
refid [10.10.10.1], задержка 0.02614, дисперсия 0.00000
передается 4, в фильтре 4
Контрольное время: 00000000.00000000 чт, 7 февраля 2036 6: 28: 16,000
время создания метки: d3a9bdc4.27ebb350 чт, 12 июля 2012 г. 21: 19: 00.155
метка времени передачи: bc17c803.b42dfffe Сб, 1 января 2000 0: 25: 39.703
задержка фильтра: 0,02625 0,02614 0,02618 0,02625 
         0,00000 0,00000 0,00000 0,00000 
смещение фильтра: 39544160 39544160 39544160 39544160
         0,000000 0,000000 0,000000 0,000000
задержка 0.02614, дисперсия 0.00000
смещение 395441600.451568

 1 января 00:25:39 ntpdate [677]: не найден сервер, подходящий для синхронизации

Я предполагаю, что машина А просто не доверяет себе в обслуживании. Через 51 минуту (возможно, это произошло раньше, я не знаю) времени безотказной работы и синхронизации часов с GPS, машина A начала правильно показывать время, и машина B подняла его. Мне нужно, чтобы это случилось раньше. Мол, в течение нескольких секунд, если это возможно.

Со следующими конфигами (и большим количеством ожидания) это в конечном счете преуспевает.

Машина A ntp.conf:

сервер 127.127.28.0 предпочитают true minpoll 4 maxpoll 4
выдумка 127.127.28.0 слой 1 раз1 0.420 refid GPS 

Машина B ntp.conf:

сервер 10.10.10.1 предпочитают true minpoll 4 maxpoll 4

Ntpq -c на машине B без исправления времени:

     дистанционный refid st t, когда опрос достигает задержки смещения джиттера
================================================== ============================
 10.10.10.1 .STEP. 16 u 9 16 0 0,000 0,000 0,000

Ntp1 -c на машине B однозначно исправляет время:

     дистанционный refid st t, когда опрос достигает задержки смещения джиттера
================================================== ============================
* 10.10.10.1 SHM (0) 2 u 7 16 17 0.669 2.597 1.808

Итак, теперь возникает вопрос: как мне сделать так, чтобы машина A быстро доверяла себе?

Некоторая отладочная информация с машины A до и после машины B решает, что машина A достаточно хороша для использования.

перед..

~ # ntpq -c rv
associd = 0 status = c418 leap_alarm, sync_uhf_radio, 1 событие, no_sys_peer,
версия = "ntpd 4.2.6p4@1.2324 пт 24 февраля 15:01:45 UTC 2012 (1)",
процессор = "armv7l", система = "Linux / 2.6.35.14", скачок = 11, уровень = 2,
точность = -19, rootdelay = 0,000, rootdisp = 44,537, refid = SHM (0),
reftime = d3ab0053.43b44780 Пт, 13 июля 2012 20: 15: 15.264,
часы = d3ab0062.e7e03154 пт, 13 июля 2012 20: 15: 30,905, peer = 34819, tc = 4,
mintc = 3, смещение = 0,000, частота = 0,000, sys_jitter = 3,853,
clk_jitter = 36,492, clk_wander = 0,000

после...

~ # ntpq -c rv
associd = 0 статус = 0415 leap_none, sync_uhf_radio, 1 событие, clock_sync,
версия = "ntpd 4.2.6p4@1.2324 пт 24 февраля 15:01:45 UTC 2012 (1)",
процессор = "armv7l", система = "Linux / 2.6.35.14", скачок = 00, уровень = 2,
точность = -19, rootdelay = 0,000, rootdisp = 41.278, refid = SHM (0),
reftime = d3ab0063.43b37856 пт, 13 июля 2012 20: 15: 31.264,
часы = d3ab006d.9ee53ec2 пт, 13 июля 2012 20: 15: 41.620, peer = 34819, tc = 4,
mintc = 3, смещение = 0,000, частота = 43,896, sys_jitter = 0,762,
clk_jitter = 36,953, clk_wander = 0,000

NTP должен работать нормально. Посмотрите на некоторые варианты быстрой синхронизации при запуске. Посмотрите на burstи iburstварианте системы B. Посмотрите на 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-сервера. Понимание того, что происходит с сервером А, должно иметь большое значение для решения вашей проблемы. Вам понадобится как минимум один доверенный источник времени, прежде чем сервер B сможет доверять ему. Если ntpq -c peersне работает, то вы можете попробовать ntpdc peers. Обе эти команды позволяют запрашивать другие хосты. peerstatsЖурнал также может быть полезным.

На сервере B используйте ntpclient, как описано в документации о busybox ntp, чтобы регистрировать происходящее на нем.

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

'ntpd -q' быстро синхронизируется, но завершается (поведение ntpdate). За ней должна следовать ntpdкоманда без опции quit, чтобы иметь непрерывную синхронизацию.

РЕДАКТИРОВАТЬ 2: Я проверяю свой сервер и обнаружил, что один из серверов был отключен на секунду. Исправляя это, я играл с настройками. iburstочень быстро получает доверие к серверу trueГарантировал, что драйвер часов был доверенным, если не было нескольких других доверенных источников. Часы потратили чуть больше минуты, прежде чем им стали доверять локально, и им можно было доверять удаленно.

При тестировании вы должны иметь возможность перезапустить ntpdпроцесс после его синхронизации и проверить, насколько быстро работают настройки. В приведенном выше случае, возможно, потребуется перезапустить сервер B, чтобы проверить, насколько быстро он синхронизируется. При мониторинге ntpdизменений я использую строку вроде:

while ntpq -c peers localhost; do sleep 10; done

Имя хоста и время ожидания корректируются по мере необходимости. В некоторых случаях я ntpqзацикливаю две или более командных строки в цикле. При этом я использую команду echo и / или date, чтобы указать, где меняются наборы данных.