NTP/Chrony 無法在 CentOS 7.9 上保持時間同步(VM 在 VMware ESXi 上運作)

NTP/Chrony 無法在 CentOS 7.9 上保持時間同步(VM 在 VMware ESXi 上運作)

我在資料中心 (VMware ESXi) 中有 3 台運行 CentOS 7.9.2009 的伺服器。這些伺服器報告時間不同步。我在內部 VMware ESXi 伺服器上運行了一個類似的測試環境,其中伺服器同步。時間還好。生產環境最初是以完全相同的方式設定的 - 但顯然隨著時間的推移隨著軟體包的更新而更新。所以它們“應該”是相同的 - 但我不能再保證這一點。 ESXi 伺服器均為版本 6。

伺服器最初是使用“ntpd”配置的 - 但在過去幾天解決此問題時,我發現“Chrony”似乎是 CentOS 7 上更好的選擇。

編輯:用於更改為 Chrony 的步驟

  • 百勝安裝 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

如果我使用systemctl restart chronyd然後在幾秒鐘後timedatectl報告重新啟動 Chrony:

      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

在最後一種情況下,一段時間後它將再次顯示第一個輸出。但「在......毫秒內」似乎相當高?

因為我可以透過重新啟動 Chrony 來同步它,所以我猜防火牆/網路是好的。我使用預設的 Chrony 配置(就像我之前對 ntpd 所做的那樣)。

VMwaretools 服務已安裝並啟動(open-vm-tools、http://github.com/vmware/open-vm-tools)。

我將不勝感激任何進一步解決此問題的建議 - 並最終解決它;-)

先致謝!

/約翰

答案1

我想我現在已經解決了。

基本上,chrony 認為時間變化太大了。因此,按照 Peter Rosenberg 的連結(及其連結的資源),我進入了軌道...

我已將此資訊放在這裡,以防其他人搜尋它。

過程的第一步是來自 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

現在它已經運行了一段時間,並且似乎保持了時間同步;-)

編輯:

正如 Paul Gear 指出的那樣,我還沒有解決問題……時間仍然在流逝。

使用/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/ 當達到漂移的閾值時,它會放棄同步,這似乎發生在你身上。

相關內容