データ センター (VMware ESXi) に CentOS 7.9.2009 を実行しているサーバーが 3 台あります。これらのサーバーは、時刻が同期されていないと報告しています。社内の VMware ESXi サーバーで同様のテスト環境を実行していますが、サーバーは時刻を同期しています。時刻は正常です。実稼働環境は、当初はまったく同じ方法でセットアップされていましたが、時間の経過とともにパッケージの更新によって更新されたことは明らかです。したがって、それらは「同一」であるはずですが、もはやそれを保証することはできません。ESXi サーバーは両方ともバージョン 6 です。
サーバーは元々「ntpd」を使用して構成されていましたが、過去数日間この問題のトラブルシューティングを行ったところ、CentOS 7 では「Chrony」の方が適していると思われることがわかりました。そのため、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
最後のケースでは、しばらくすると最初の出力が再び表示されます。しかし、「... ミリ秒以内」はかなり高いようです???
Chrony を再起動することで同期できるので、ファイアウォール/ネットワークは正常だと思います。デフォルトの Chrony 設定を使用します (以前 ntpd で行ったように)。
VMwaretoolsサービスがインストールされ、起動されます(open-vm-tools、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 ホストとの時刻の同期が有効になっていることがわかりました (!!!)。どうしてこうなったのかわかりません。私が最初に構成してデータ センターの担当者にアップロードした VM では、これが有効になっていませんでした。いずれにしても、明らかに、ホストと時刻を同期するべきではありません。
以下の方法を使用すると、簡単に無効にできます。/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
今では 30 分間スムーズに動作しているので、これが解決策であると確信しています。ご意見ありがとうございます。
答え2
ここで提案されている最小限のクライアント設定を使用することを検討してください。https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/ ドリフトのしきい値に達すると、同期が中止されます。これは、あなたにも起こっているようです。