chrony設定のベストプラクティス【Linux時刻同期の実務設計】

URLをコピーしました！

chrony は、現在の Linux ディストリビューションで標準採用されている NTP（時刻同期）デーモンです。

一方で、

「デフォルト設定のまま使っている」
「同期しているか実はよく分かっていない」
「障害時の挙動を理解していない」

といったケースも非常に多く見られます。

本記事では、実務で安定運用するための chrony 設定ベストプラクティスを、理由付きで解説します。

chrony を正しく設計すべき理由

ログの時系列整合性
証明書・認証（TLS / Kerberos）
クラスタ・分散システム
監視・障害解析

時刻同期は「ズレたら直せばいい」ではなく、 ズレない設計が重要です。

ベストプラクティス①：NTPサーバーは複数指定する

理由

単一NTPサーバー障害に弱い
ネットワーク分断時に同期不能

推奨設定例

server ntp1.example.com iburst
server ntp2.example.com iburst
server ntp3.example.com iburst

ポイント

最低 3 台以上
異なるネットワーク・拠点
社内NTP + 公開NTPの併用も可

ベストプラクティス②：iburst を必ず指定する

iburstとは

起動直後に高速で時刻差を測定するオプションです。

指定しない場合の問題

起動後しばらく同期しない
時刻ズレが長時間残る

→ 原則必須です。

ベストプラクティス③：makestep を有効活用する

大きな時刻ズレ問題

chrony は通常、時刻を徐々に補正します。

数分〜数時間ズレている
初回起動直後

では、補正に非常に時間がかかります。

推奨設定

makestep 1.0 3

意味

1.0秒以上ズレていたら
起動後3回まで即時補正

→ 初回同期トラブルを防止

ベストプラクティス④：RTC（ハードウェアクロック）を正しく扱う

推奨

RTC は UTC で管理
OS 側でタイムゾーン制御

設定例

timedatectl set-local-rtc 0

再起動後にズレる環境では必須確認ポイントです。

ベストプラクティス⑤：allow 設定は慎重に

chronyをNTPサーバーとして使う場合

allow 192.168.0.0/24

注意点

不要な範囲を許可しない
外部公開は原則NG

誤設定するとNTP増幅攻撃の踏み台になる可能性があります。

ベストプラクティス⑥：FWでUDP/123を明示的に許可

「サービスは起動しているのに同期しない」場合、 FWが原因のケースが非常に多いです。

確認例

firewall-cmd --list-services
iptables -L -n

UDP/123 の送信・受信を忘れずに。

ベストプラクティス⑦：仮想環境では二重同期を避ける

NGパターン

chrony 同期
VMware Tools 時刻同期

→ 競合して時刻ドリフトの原因

推奨

chrony に一本化
仮想化基盤の同期は無効化

運用時の定期チェックコマンド

同期状態確認

chronyc tracking
chronyc sources -v

想定される正常状態

Leap status : Normal
^* の同期サーバーが存在

よくある設定ミスと影響

ミス	影響
NTPサーバー1台のみ	障害時に同期不可
iburstなし	起動後同期が遅い
FW未設定	常に未同期
RTC設定ミス	再起動後にズレる

まとめ

chronyは「設定して終わり」ではない
複数NTP・iburst・makestepは必須
仮想環境・FW・RTCまで含めて設計
定期的な同期状態確認が安定運用の鍵

時刻はインフラの基準軸です。正しく設計・運用することで、多くの障害を未然に防げます。