chrony/NTPの設定間違いで時刻同期が崩壊『サーバOSの話⑩』
サーバ運用で最も“地味だが致命的”なのが 時刻同期の崩壊。
アプリのログが並ばない、DBレプリケーションが破綻、
証明書やトークン認証が失敗──。
原因が chrony/NTP の設定ミス というのは、現場で本当によくある。
時刻はインフラの基準。
これが揃わないと、上のレイヤはすべて崩れる。
ひと言まとめ
NTP/chrony の設定ミスは“静かに壊す”タイプの事故。
サーバ同士の時刻がズレると、障害解析・認証・レプリケーション全部が狂う。
症状（あるある）
サーバごとにログ時刻がバラバラ
監視アラートと OS のログが一致しない
DBレプリケーションで “clock skew” エラー
TLS証明書やJWTトークンの期限判定で失敗
アプリのセッション周りだけ謎の不具合
chronyc sources が “? UNREACH” だらけ
仮想環境でホストとVMの時刻が揃わない
原因と仕組み（なぜ起きる？）
chrony と ntpd が 両方インストールされて競合
“server” と “pool” の使い方ミス
上位NTPサーバのIP/ホスト名が間違い
ファイアウォールで UDP/123 が閉じている
仮想環境で ホストとゲストが互いに時刻修正 してズレ続ける
RTC（ハードウェアクロック）が UTC/JST どちらかに統一されていない
cloud-init が別の NTP 設定を上書き
図：NTP不達 → サーバが勝手に時刻を進めたり遅らせたりする
[上位NTP] ×（到達不可）
│
▼
[サーバ] ← 自己判断で時刻調整 → ログがズレる・認証失敗
切り分け（最短コース）
使用しているサービスを確認（chrony or ntpd）
systemctl status chronyd systemctl status ntpd
同期状態確認
chronyc tracking chronyc sources -v
上位NTPへの疎通確認
nc -uvz <NTP_SERVER> 123
時刻の現在値チェック
date
仮想環境ならホスト側のタイムソースを確認
VMware/Hyper-V/KVM で “時刻同期” の二重化に注意。
今すぐ効く対処（テンプレ）
◆ chrony を正しく設定（RHEL系例）
/etc/chrony.conf
server ntp.example.com iburst
# または
pool 0.jp.pool.ntp.org iburst
サービス再起動
systemctl restart chronyd
即時同期（強制）
chronyc makestep
競合する ntpd を無効化
systemctl disable --now ntpd
◆ FW の UDP/123 を開放
NTPは 必ずUDP/123。ここを閉じているケースが非常に多い。
◆ 仮想環境の“二重同期”を無効化
VM Tools の時刻同期を切る
もしくは chrony を無効化しホストに統一する（どちらか一方）
恒久対策／再発防止チェックリスト
chrony と ntpd の“どちらを使うか”を統一
上位NTPサーバを企業内で一本化
UDP/123 の通信経路を保証
cloud-init の NTP 設定上書きを防止
仮想環境でホスト/ゲストの同期方式を明確化
chronyc tracking を監視に組み込む
RTC（ハードウェアクロック）は UTC 統一
NTPサーバ側の負荷・可用性も定期点検
落とし穴（やりがちミス）
chrony.conf の “server” と “pool” を混在
pool.ntp.org を firewall がブロック
複数NTPサーバを設定したが、1つだけ間違ったIPで固まる
cloud-init で設定を上書きされ chrony.conf が無視される
仮想環境でホストとVMが“時刻の押し合い”をしてズレ続ける
変更後の確認ポイント
chronyc sources が ^* で同期状態
offset（ズレ幅）が数ミリ秒〜数十ミリ秒で安定
ログ時刻と実際の時刻が一致
監視アラートの発生時刻と整合
VMとホストの同期方式が一貫している
まとめ（行動指針）
時刻同期は“インフラの基準線”。
ここが狂うと、ログ・認証・レプリケーションがすべて崩れる。
chrony/ntpd を一本化 → 上位NTPを正しく設定 → 同期状態を監視。
これだけで時刻同期の崩壊はほぼ防げる。