NTP / Chrony не поддерживает синхронизацию времени на CentOS 7.9 (виртуальная машина, работающая на VMware ESXi)
У меня есть 3 сервера под управлением CentOS 7.9.2009 г. в дата-центре (VMware ESXi). Эти серверы сообщают, что время не синхронизировано. У меня есть аналогичная тестовая среда, работающая на собственном сервере VMware ESXi, где серверы синхронизируются. время Ок. Производственная среда изначально была настроена точно так же, но, очевидно, со временем обновлялась за счет обновлений пакетов. Значит, они «должны» быть идентичными - но я больше не могу этого гарантировать. Оба сервера ESXi имеют версию 6.
Первоначально серверы были настроены с использованием «ntpd», но при устранении этой проблемы за последние пару дней я обнаружил, что «Chrony» кажется лучшим выбором для CentOS 7. I поэтому перенастроили серверы для использования Chrony - но проблема все еще есть.
Изменить: шаги, используемые для перехода на Chrony
- yum install chrony
- systemctl stop ntpd
- systemctl disable ntpd
- systemctl start chronyd
- systemctl enable chronyd
Итак, когда я использую timedatectl Я получаю следующий результат:
Local time: Mon 2021-08-02 09:14:43 CEST
Universal time: Mon 2021-08-02 07:14:43 UTC
RTC time: Mon 2021-08-02 07:16:34
Time zone: Europe/Copenhagen (CEST, +0200)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2021-03-28 01:59:59 CET
Sun 2021-03-28 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2021-10-31 02:59:59 CEST
Sun 2021-10-31 02:00:00 CET
Если я перезапущу Chrony с помощью systemctl restart chronyd , то через пару секунд timedatectl сообщает:
Local time: Mon 2021-08-02 09:26:06 CEST
Universal time: Mon 2021-08-02 07:26:06 UTC
RTC time: Mon 2021-08-02 07:26:08
Time zone: Europe/Copenhagen (CEST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2021-03-28 01:59:59 CET
Sun 2021-03-28 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2021-10-31 02:59:59 CEST
Sun 2021-10-31 02:00:00 CET
Через некоторое время (минуты ) он вернулся к NTP синхронизирован: нет .
Когда я запускаю ntpstat , я получаю:
synchronised to NTP server (217.198.219.102) at stratum 2
time correct to within 124123 ms
polling server every 64 s
или
unsynchronised
poll interval unknown
В последнем случае через некоторое время снова будет показан первый вывод. Но "в пределах ... мс" кажется довольно высоким ???
Поскольку я могу синхронизировать его, перезапустив Chrony, я думаю, что брандмауэр / сеть в порядке. Я использую конфигурацию Chrony по умолчанию (как и раньше с ntpd).
Служба VMwaretools установлена и запущена (open-vm-tools, http://github.com/vmware/open-vm-tools ).
Буду признателен за любые предложения по дальнейшему устранению неполадок - и, в конечном итоге, исправлению; -)
Заранее спасибо!
/ Джон
Рассмотрите возможность использования минимальной настройки клиента, как предлагается здесь: https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ Когда достигается порог дрейфа, он отказывается от синхронизации, что, кажется, происходит с вами.
Кажется, теперь я решил эту проблему.
По сути, хроний считал, что время слишком сильно разнится. Итак, перейдя по ссылке Питера Розенберга (и ресурсам, на которые она ссылалась), я попал на след....
Я поместил эту информацию здесь на случай, если кто-то еще ее ищет.
Первыми шагами в процессе был статус от сервиса chronyd:
systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-08-02 22:23:39 CEST; 10h ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 24758 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
Process: 24754 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 24756 (chronyd)
CGroup: /system.slice/chronyd.service
└─24756 /usr/sbin/chronyd
Aug 03 08:41:24 db1.aqua.dtu.dk chronyd[24756]: Selected source 162.159.200.1
Aug 03 08:41:24 db1.aqua.dtu.dk chronyd[24756]: System clock wrong by 5.118732 seconds, adjustment started
Aug 03 08:41:26 db1.aqua.dtu.dk chronyd[24756]: Can't synchronise: no majority
Aug 03 08:41:33 db1.aqua.dtu.dk chronyd[24756]: Selected source 162.159.200.123
Aug 03 08:41:33 db1.aqua.dtu.dk chronyd[24756]: System clock wrong by 1.761045 seconds, adjustment started
Aug 03 08:42:29 db1.aqua.dtu.dk chronyd[24756]: Can't synchronise: no majority
Aug 03 08:42:30 db1.aqua.dtu.dk chronyd[24756]: Selected source 192.36.143.130
Aug 03 08:42:30 db1.aqua.dtu.dk chronyd[24756]: System clock wrong by 4.500188 seconds, adjustment started
Aug 03 08:43:34 db1.aqua.dtu.dk chronyd[24756]: System clock wrong by 4.842190 seconds, adjustment started
Aug 03 08:44:39 db1.aqua.dtu.dk chronyd[24756]: Can't synchronise: no selectable sources
Он явно показывал, что что-то не так. Итак, следующим шагом было:
chronyc sources -v
210 Number of sources = 4
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^~ time.cloudflare.com 3 6 377 1 -17.0s[ -17.0s] +/- 1318us
^~ Time100.Stupi.SE 1 6 377 2 -16.9s[ -16.9s] +/- 4458us
^~ time.cloudflare.com 3 6 377 53 -11.2s[ -11.2s] +/- 1306us
^~ n1.taur.dk 1 6 377 60 -10.4s[ -10.4s] +/- 4964us
Обратите внимание на слишком переменное время для всех серверов....
И хроническое отслеживание также показывает, что время не выровнено в all:
Reference ID : C0248F82 (Time100.Stupi.SE)
Stratum : 2
Ref time (UTC) : Tue Aug 03 06:46:05 2021
System time : 132.970306396 seconds slow of NTP time
Last offset : -4.842189789 seconds
RMS offset : 7.720179081 seconds
Frequency : 63.104 ppm slow
Residual freq : -81143.852 ppm
Skew : 90.130 ppm
Root delay : 0.008654756 seconds
Root dispersion : 19.424978256 seconds
Update interval : 58.2 seconds
Leap status : Normal
Почитав еще ссылки на статьи, я попытался настроить makestep в файле /etc/chrony.conf для принудительного обновления. Я уже изменил серверы пула NTP, чтобы они были «ближе» к серверам приложений, поэтому файл конфигурации теперь выглядит так:
server 0.dk.pool.ntp.org iburst
server 1.dk.pool.ntp.org iburst
server 2.dk.pool.ntp.org iburst
server 3.dk.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1 -1
rtcsync
Он работает некоторое время и, похоже, синхронизирует время ;-)
РЕДАКТИРОВАТЬ:
Как указал Пол Гир, я не решил проблему... Время все еще дрейфовало.
Используя /usr/bin/vmware-toolbox-cmd timesync status я обнаружил, что на рабочих серверах синхронизация времени с хостом ESXi была ВКЛЮЧЕНА (!!!). Я понятия не имею, как это произошло? Виртуальная машина, которую я изначально настроил и загрузил в центр обработки данных, не была включена. В любом случае, очевидно, он не должен синхронизироваться. время с хозяином.
Его довольно легко отключить с помощью: /usr/bin/vmware-toolbox-cmd timesync disable
И теперь у нас есть более реалистичные данные из хронических источников -v:
210 Number of sources = 4
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- sweetums.eng.tdc.net 2 7 377 36 +30us[ +30us] +/- 45ms
^* 77.68.139.83 1 7 377 92 -191us[ -184us] +/- 4742us
^- 152.115.59.244 2 7 377 39 +99us[ +99us] +/- 31ms
^- pf.safe-con.dk 2 7 377 42 +359us[ +359us] +/- 29ms
, а также хроническое отслеживание:
Reference ID : 4D448B53 (77.68.139.83)
Stratum : 2
Ref time (UTC) : Tue Aug 03 10:45:26 2021
System time : 0.000008465 seconds slow of NTP time
Last offset : +0.000006720 seconds
RMS offset : 7.358564854 seconds
Frequency : 57.633 ppm slow
Residual freq : +0.001 ppm
Skew : 0.340 ppm
Root delay : 0.009058274 seconds
Root dispersion : 0.000351956 seconds
Update interval : 128.8 seconds
Leap status : Normal
Вот уже полчаса все работает без сбоев, поэтому я уверен, что это решение. Спасибо за вклад!!!