Назад | Перейти на главную страницу

Системное время отключается на сотни миллисекунд, несмотря на синхронизацию NTP перед загрузкой

Я запускаю несколько серверов, которым требуется довольно жесткая временная синхронизация (<50 мс), поскольку они работают по алгоритму Paxos. На серверах работает протокол NTP, и они успешно синхронизируются в одной точке. В соответствии с hwclock 11-минутный механизм включен, поэтому системное время должно быть скопировано в аппаратные часы.

Однако я вижу, что после перезагрузки системное время может отключиться на целых 300 мс по сравнению со временем непосредственно перед перезагрузкой. Разве неразумно думать, что после перезагрузки время должно быть в пределах 50 мсек от времени непосредственно перед перезагрузкой?

У меня нет цифр, но вполне вероятно, что интерфейс, используемый для установки часов при загрузке, имеет точность до секунды.

Вы не указываете свою ОС, но во всех Unix-подобных системах можно вставить зависимость от времени NTP в процесс загрузки.

Демон NTP запускается при загрузке, но часто он немедленно запускается в фоновом режиме и загрузка продолжается, в то время как демон NTP ищет серверы для синхронизации - это сделано для того, чтобы загрузка не откладывалась, если машина не подключена к сети.

В этом случае вы захотите убедиться, что демон ntp запущен таким образом, чтобы исправить смещение, выполняя шаги при загрузке. Это может быть, например, ntpd -gx или chronyc -q. Вы также можете вставить проверку, что смещение приемлемо, прежде чем начинать вашу рабочую нагрузку.

Моя первая реакция заключалась в том, что 300 мс - это ужасно много, но у меня есть цифры, которые нужно привести, и они показывают, что @ Law29 прав:

  1. Одна из моих машин за нормальную неделю:
    • Частота:
    • Смещение однорангового узла системы:
  2. Та же система, более короткий период с перезагрузкой:
    • Частота:
    • Смещение однорангового узла системы:
    • Диаграмма разброса сверстников

(Надеюсь, вы хорошо прочитаете все числа на графиках - напишите мне комментарий, если нет.)

Как видите, есть довольно большое расхождение. Меня удивило, сколько это было, а также сколько времени потребовалось, чтобы вернуться к правильной работе с частотной коррекцией, учитывая, что в моей локальной сети есть источник GPS уровня 1. А учитывая, что одноранговые образцы довольно плотно сгруппированы на графике, очевидно, что это проблема с локальными часами, а не с несогласованной сетевой задержкой во время запуска. (Для справки, оборудование - это Шаттл DS437 безвентиляторный мини-ПК с двухъядерным процессором Celeron 1037U @ 1,8 ГГц.)

Итак, выводы, вероятно, следующие:

  1. убедитесь, что ntpd успешно записывает дрейфовый файл NTP,
  2. убедитесь, что 11-минутный таймер ядра для обновления аппаратных часов включен (см. «Автоматическая синхронизация аппаратных часов ядром» в man hwclock для подробностей), или в процессе выключения обновляются аппаратные часы,
  3. убедитесь, что у ntpd есть 4-10 доступных источников (в режиме iburst), и
  4. настройте зависимости при запуске, чтобы у ntpd была возможность исправить часы до запуска Paxos.