☰

NTP/Chrony не синхронизирует время на CentOS 7.9 (виртуальная машина работает на VMware ESXi)

tag-icon • tag-icon centos7 time-synchronization ntpd chrony
NTP/Chrony не синхронизирует время на CentOS 7.9 (виртуальная машина работает на VMware ESXi)

У меня есть 3 сервера под управлением CentOS 7.9.2009 в центре обработки данных (VMware ESXi). Эти серверы сообщают, что время не синхронизировано. У меня есть похожая тестовая среда, работающая на внутреннем сервере VMware ESXi, где серверы синхронизируются. время ОК. Производственная среда была изначально настроена точно так же, но, очевидно, со временем обновлялась обновлениями пакетов. Так что они «должны» быть идентичными, но я больше не могу этого гарантировать. Оба сервера ESXi имеют версию 6.

Первоначально серверы были настроены с использованием «ntpd», но при устранении этой проблемы в течение последних нескольких дней я обнаружил, что «Chrony» кажется лучшим выбором на CentOS 7. Поэтому я перенастроил серверы для использования Chrony, но проблема все еще осталась.

Редактировать: шаги, используемые для перехода на Chrony

  • yum установить chrony
  • systemctl остановить ntpd
  • systemctl отключить ntpd
  • systemctl запустить chronyd
  • systemctl включить 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 synchronized: no.

Когда я бегу, 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

В последнем случае через некоторое время снова появится первый вывод. Но "in within ... ms" кажется довольно высоким???

Поскольку я могу синхронизировать его, перезапустив Chrony, то я предполагаю, что с брандмауэром/сетью все в порядке. Я использую конфигурацию Chrony по умолчанию (как я делал это с ntpd раньше).

Служба VMwaretools установлена ​​и запущена (open-vm-tools,http://github.com/vmware/open-vm-tools).

Я был бы признателен за любые предложения по дальнейшему устранению неполадок и в конечном итоге их устранению ;-)

Заранее спасибо!

/Джон

решение1

Думаю, теперь я это решил.

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

Я разместил эту информацию здесь на случай, если кто-то еще будет ее искать.

Первым шагом в этом процессе стал статус от сервиса 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

Обратите внимание time too variableна все серверы....

А chronyc trackingтакже показывает, что время вообще не выровнено:

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

И теперь у нас есть более реалистичные данные от 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               
===============================================================================
^- 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

а также chronyc tracking:

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

Теперь он работает гладко уже полчаса, поэтому я уверен, что это решение. Спасибо за вклад!!!

решение2

Рассмотрите возможность использования минимальной настройки клиента, как предложено здесь:https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ Когда достигается порог дрейфа, синхронизация прекращается, что, по-видимому, и происходит с вами.

Связанный контент