Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Unix-подобные системы

Как исправить чрезмерно длинное время синхронизации ntpd?

На чтение 9 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Как устранить проблемы с длительным синхронизацией NTP (ntpd) на Raspberry Pi?
  4. Основные причины длительной синхронизации ntpd
  5. Рекомендации по устранению длительной задержки синхронизации
  6. Пример обновленного файла конфигурации NTP
  7. Заключение

Вопрос или проблема

Я в настоящее время испытываю невероятно долгие задержки синхронизации с ntpd и после множества поисков в Google решил начать новую тему, так как все «меры» не сработали. Машина, о которой идет речь, — это Raspberry Pi 3B с операционной системой Raspi OS ‘Buster’ (образ lite/non-GUI от 5/7/21). Поскольку она будет основным узлом для небольшого кластера, у нее два сетевых интерфейса: eth0 (встроенный сетевой интерфейс и внутренний интерфейс) настроен на 192.168.4.100/24, а eth1 (USB-ключ и внешний интерфейс) — на 192.168.1.220/24. В настоящее время я использую dhcpcd для настройки интерфейсов и определил DNS-серверы в /etc/resolvconf.conf. ntpd в конечном итоге синхронизируется, но только через несколько часов и после перезагрузки Pi, несмотря на то, что fake-hwclock сохраняет время в /etc/fake-hwclock.data, ntpd снова начинает с нуля и начинает несколько часов длительный процесс синхронизации. Я должен отметить, что время, сохраненное в /etc/fake-hwclock, — это время UTC, а не время, скорректированное по часам, но я не думаю, что это повлияет на время синхронизации ntpd. Ниже приведен мой файл /etc/ntp.conf. Комментарий к строке ‘tinker panic 0’ похоже, не влияет на синхронизацию.

В целом, мои вопросы:

Как я могу сократить время задержки синхронизации?

Если я перезагружу Pi после синхронизации ntpd, команда ‘date’ выдаст мне правильное время, НО ntpd снова окажется в начальной точке, и потребуется несколько часов для синхронизации. Как этого избежать? (Логика подсказывает, что не должно пройти много времени для согласования локального и удаленного времени, когда они отличаются всего на несколько секунд.)

systemd-timesyncd отключен.

Файл /etc/ntp.conf
# /etc/ntp.conf, конфигурация для ntpd; см. ntp.conf(5) для получения справки

#tinker panic 0

driftfile /var/lib/ntp/ntp.drift

# Определение висекунд, предоставленное tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

# Включите это, если хотите, чтобы статистика записывалась.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Вам нужно связаться с одним или двумя (или тремя) NTP-серверами.

server time-a-g.nist.gov iburst
server time-a-wwv.nist.gov iburst

server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst

# Конфигурация контроля доступа; см. /usr/share/doc/ntp-doc/html/accopt.html для подробностей.
# Веб-страница также может быть полезной.
#
# По умолчанию обмен времени со всеми, но не разрешать конфигурацию.
restrict -4 default kod notrap nomodify nopeer noquery limited

# Локальные пользователи могут более детально опросить сервер ntp.
restrict 127.0.0.1

# Необходимо для добавления записей пула
restrict source notrap nomodify noquery

# Если хотите предоставить время своей локальной подсети, измените следующую строку.
# (Снова, адрес — это только пример.)

broadcast 192.168.4.255

Вывод команд ‘uptime’ и ‘ntpq -p’ в 11:07 AM CDT (согласно часам моего MacBook Pro):
charles@Chimera-Head-Node:~ $ uptime
10:12:52 up 34 мин, 1 пользователь, средняя загрузка: 0.00, 0.00, 0.00
charles@Chimera-Head-Node:~ $ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.4.255 .XFAC. 16 B – 64 0 0.000 0.000 0.002
time-a-g.nist.g .INIT. 16 u – 1024 0 0.000 0.000 0.000
time-a-wwv.nist .INIT. 16 u – 1024 0 0.000 0.000 0.000
ec.sedley.net .INIT. 16 u – 1024 0 0.000 0.000 0.000
ntp1.doctor.com .INIT. 16 u – 1024 0 0.000 0.000 0.000

Примечание: Каждый раз, когда я загружаю или перезагружаю Pi, адрес широковещательной рассылки всегда отображается как .XFAC. для refid. Если я просто выполню ‘sudo service ntp restart’, refid изменится на .BCST. (так, как он должен быть). Я пока не исправил эту проблему, и, хотя это будет вопрос для другой темы, любые советы приветствуются 🙂
Вывод syslog при загрузке (пункты, не касающиеся ntpd/dhcpcd, удалены):
Sep 1 09:38:53 Chimera-Head-Node ntpd[546]: ntpd [email protected] (1): Запуск
Sep 1 09:38:53 Chimera-Head-Node ntpd[546]: Командная строка: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 109:114
Sep 1 09:38:53 Chimera-Head-Node systemd[1]: Запущена служба сетевого времени.
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: proto: precision = 1.458 usec (-19)
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: файл високосной секунды (‘/usr/share/zoneinfo/leap-seconds.list’): хорошая контрольная подпись
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: файл високосной секунды (‘/usr/share/zoneinfo/leap-seconds.list’): загружен, истекает=2021-12-28T00:00:00Z последний=2017-01-01T00:00:00Z ofs=37
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Слушаем и игнорируем на 0 v6wildcard [::]:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Слушаем и игнорируем на 1 v4wildcard 0.0.0.0:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Слушаем обычно на 2 lo 127.0.0.1:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Слушаем обычно на 3 eth1 192.168.1.220:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Слушаем обычно на 4 lo [::1]:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Слушаем обычно на 5 eth0 [fe80::ba27:ebff:fed5:8e4d%2]:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Слушаем обычно на 6 eth1 [fe80::1f2d:3bb6:af44:5cbb%3]:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Слушаем на сокете маршрутизации на fd #23 для обновлений интерфейса
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: ядро сообщает TIME_ERROR: 0x41: Часы не синхронизированы
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: ядро сообщает TIME_ERROR: 0x41: Часы не синхронизированы
Sep 1 09:38:54 Chimera-Head-Node dhcpcd[541]: eth0: используется статический адрес 192.168.4.100/24
Sep 1 09:38:54 Chimera-Head-Node dhcpcd[541]: eth0: добавление маршрута к 192.168.4.0/24
Sep 1 09:38:55 Chimera-Head-Node ntpd[554]: Слушаем обычно на 7 eth0 192.168.4.100:123
Sep 1 09:38:55 Chimera-Head-Node ntpd[554]: 192.168.4.255 локальный адрес 192.168.1.220 -> 192.168.4.100
Sep 1 09:38:55 Chimera-Head-Node ntpd[554]: найдены новые интерфейсы: пробуждаем резолвера
Sep 1 09:39:01 Chimera-Head-Node dhcpcd[541]: eth1: нет доступных маршрутизаторов IPv6
Sep 1 09:39:03 Chimera-Head-Node dhcpcd[541]: eth0: нет доступных маршрутизаторов IPv6

(Перемещено сюда, так как изначально было частью текста вопроса). Проблема была решена (я просто не имел возможности опубликовать это до сих пор). Решение состояло из двух частей:

Хотя мой маршрутизатор Synology RT-2600ac имел службу NTP включенной и, по теории, порт 123 был открыт, я отключил службу и затем создал правило брандмауэра, которое явно открыло UDP-порт 123 с любого IP-адреса на любой IP-адрес.

Ниже приведены файлы ntp.conf, которые я теперь использую. Хотя я не знаю, можно ли удалить команды интерфейса в верхней части ntp.conf узла, я почти уверен, что строка restrict для сети 192.168.4.0 сделала свою работу для распространения NTP по сети 192.168.4.0.

Файл ntp.conf основного узла кластера
# /etc/ntp.conf, конфигурация для ntpd; см. ntp.conf(5) для получения справки

# по умолчанию не слушаем ничего
#
interface ignore all

# Слушаем на внутреннем интерфейсе
#
interface listen 192.168.4.100/24

# Слушаем на внешнем интерфейсе
#
interface listen 192.168.1.220/24

driftfile /var/lib/ntp/ntp.drift

leapfile /usr/share/zoneinfo/leap-seconds.list

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server time-a-g.nist.gov iburst
server time-a-wwv.nist.gov iburst

server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

# По умолчанию обмен времени со всеми, но не разрешать конфигурацию.
restrict -4 default kod notrap nomodify nopeer noquery limited

# Локальные пользователи могут более детально опросить сервер ntp.
restrict 127.0.0.1

restrict 192.168.4.0 mask 255.255.255.0 nomodify

# Необходимо для добавления записей пула
restrict source notrap nomodify noquery

Файл ntp.conf вычислительного узла кластера
# /etc/ntp.conf, конфигурация для ntpd; см. ntp.conf(5) для получения справки

driftfile /var/lib/ntp/ntp.drift

# Определение висекунд, предоставленное tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Вам нужно связаться с одним или двумя (или тремя) NTP-серверами.

server 192.168.4.100 iburst

# По умолчанию обмен времени со всеми, но не разрешать конфигурацию.
restrict -4 default kod notrap nomodify nopeer noquery limited

# Локальные пользователи могут более детально опросить сервер ntp.
restrict 127.0.0.1

# Необходимо для добавления записей пула
restrict source notrap nomodify noquery

Пока что вышеуказанные файлы работают хорошо.

Ответ или решение

Как устранить проблемы с длительным синхронизацией NTP (ntpd) на Raspberry Pi?

Если вы сталкиваетесь с чрезмерно долгими задержками при синхронизации времени на вашем Raspberry Pi 3B с операционной системой Raspi OS ‘Buster’, это может оказывать негативное влияние на работу вашего кластера. Давайте подробно рассмотрим возможные причины проблемы и пути их решения.

Основные причины длительной синхронизации ntpd

  1. Неправильная конфигурация сети:

    • Ваше устройство может находиться в сети с неправильными маршрутами или конфигурацией, которая препятствует доступу к NTP-серверам.

  2. Проблемы с доступом к NTP-серверам:

    • Убедитесь, что внешние NTP-серверы, такие как time-a-g.nist.gov и 0.debian.pool.ntp.org, доступны из вашей сети. Это можно проверить с помощью команды ping или traceroute.

  3. Заслуженное время и влияние аппаратного времени:

    • Если аппаратные часы вашего Raspberry Pi неправильно настроены, ntpd может требовать значительное время для коррекции. Убедитесь, что время, сохраненное в файле /etc/fake-hwclock.data, совпадает с UTC.

  4. Версии и настройки NTP:

    • Конфигурация самого NTP может быть неправильной, особенно параметры, касающиеся доступа и ограничения.

Рекомендации по устранению длительной задержки синхронизации

  1. Конфигурация NTP:
    Ваша конфигурация ntp.conf хороша, но попробуйте следующие изменения:

    • Используйте iburst для улучшения первичной синхронизации. Это позволит ntpd быстрее начать общение с серверами.
    • Проверьте, действительно ли ваш ntpd слушает на IP-адресах, указанных в конфигурации. Это можно сделать с помощью команды ntpq -p для проверки статуса.

  2. Изменение параметра tinker:
    Убедитесь, что у вас строчка tinker panic 0 раскомментирована, чтобы отключить ограничения на изменения времени при старте NTP.

  3. Запуск NTP при загрузке:
    Убедитесь, что ntpd запускается автоматически после загрузки системы. Вы можете проверить статус службы с помощью команды systemctl status ntp.

  4. Используйте дополнительные NTP-серверы:
    Рассмотрите возможность добавления дополнительных NTP-серверов в ваш файл конфигурации. Например:

    server 3.pool.ntp.org iburst
server 2.pool.ntp.org iburst

  5. Обновление маршрутизатора:
    В вашем случае, отключение встроенной NTP-службы на маршрутизаторе и настройка правил брандмауэра для обеспечения доступа к UDP-порту 123 улучшили ситуацию. Всегда старайтесь тщательно проверять настройки вашего маршрутизатора.

  6. Регулярная проверка и корректировка времени:
    Настройте автоматическое обновление времени через cron или другой планировщик задач, чтобы убедиться, что ваше время регулярно корректируется.

Пример обновленного файла конфигурации NTP

Вот пример конфигурации NTP, который можно использовать для вашего кластера:

# /etc/ntp.conf, конфигурация для ntpd

# Игнорировать все интерфейсы по умолчанию
interface ignore all

# Слушать на внутреннем интерфейсе
interface listen 192.168.4.100/24

# Слушать на внешнем интерфейсе
interface listen 192.168.1.220/24

driftfile /var/lib/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# NTP серверы
server time-a-g.nist.gov iburst
server time-a-wwv.nist.gov iburst
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst

# Ограничения
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict 192.168.4.0 mask 255.255.255.0 nomodify
restrict source notrap nomodify noquery

Заключение

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

ntpd
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности