概要
「時刻同期できておらず、気付いたら時刻がズレていた！」という場合、復旧方法を間違えると大きなトラブルにつながることも。
本記事は、時刻ズレを安全に復旧する方法として、復旧手順の一例と、復旧計画の策定までの流れをまとめたものです。
主に、RHEL7、CentOS7以降でOS標準のchronyを使用した環境を対象としていますが、基本的な考え方はどのシステムでも共通です。
chrony全般の説明は以下の記事にまとめてあります。
なお、本記事はあくまで参考情報です。実際の復旧作業に際しては二次トラブルが生じないよう十分な検討と準備が必要です。
本記事の目的
- 時刻ズレによるトラブル発生リスクを把握する。
- 時刻ズレの復旧計画を適切に検討する。
まずは復旧手順の一例
稼働させたまま時刻をゆっくり修正(slew)
本記事では、状況整理や復旧計画の流れ全体について説明しますが、ひとまず例として「サーバや業務サービスを稼働させたまま時刻をゆっくり修正(slew)する」手順を記載します。
※この手順が適切かどうかは状況によるので、詳細は記事の続きをご覧ください。
仮定として、既に存在しない古いNTPサーバを参照する設定になったままのNTPクライアントについて、参照先NTPサーバの修正(＋その反映のためにchronyサービスの再起動)が必要といったケースを想定します。
時刻をゆっくり修正(slew)する場合、以下のようにchrony.confのmakestep 1.0 3行をコメントアウトしてから、chronyサービスを再起動します。
# vi /etc/chrony.conf
#makestep 1.0 3 ←コメントアウト ※さらに、必要に応じserver行やpool行の参照先NTPサーバの指定等も設定する
# systemctl restart chronyd
chrony(chronyd) のデフォルト設定では、chronyのサービス起動時にNTPサーバと大幅に時刻がズレていた場合、一気に時刻修正(stepモード)が行われます。上記の手順は、そのstepモードによる時刻修正を無効化してからchronyサービスを再起動するものです。
chronyサービスの再起動後、正常にNTPサーバと同期が開始できたとして、以下のように通常のslewモードによりゆっくり時刻同期されることを監視します。chronyはデフォルトで1秒の時刻ズレを最速12秒間で修正します(maxslewrate)。1分間の時刻ズレを修正するのにかかる時間が最速で720秒(12分)です。
$ chronyc sourcesにて、行頭が ^* になっている行が表示され、NTPサーバと時刻同期できていることを確認します。
(★マークは説明用の目印です) MS Name/IP address Stratum Poll Reach LastRx Last sample ======================================================== ^*★ ntp-server1.domain.com 1 3 111 22 -1000us[ -100ms] +/- 10ms ^? ntp-server2.domain.com 1 3 111 22 -1000us[ -100ms] +/- 10ms ※値はダミーです
また、$ chronyc trackingを間隔を置きながら何度か実行し、System time行のX.XXXX second slow(もしくはfast)…の数値が徐々に小さくなり、時刻修正が進んでいることを確認します。
$ chronyc tracking
(★マークは説明用の目印です) Reference ID : AB00123C (domain.com) … System time : 0.000000555 seconds slow of NTP time ★ … ※値はダミーです。
各設定やコマンドの詳細は、こちらの記事にまとめてあります。
業務サービスを稼働させたまま上記の操作を行う場合は、業務サービスの方に影響が無いかも随時確認します。
時刻修正が完了した後は、コメントアウトしたmakestep 1.0 3行のコメントを解除し、再度chronyを再起動しておきます。コメントアウトしたままが良ければそのままで良いです。
基本
ここからは、時刻ズレが発生した際の状況整理や復旧計画について説明します。
時刻ズレによるトラブル発生リスク
時刻を正確に扱うシステムでは、少しの時刻ズレが深刻なデータ不整合やサービス停止を引き起こす場合があります。データベースシステム、認証系システム(SSO全般、Kerberos、TOTP)等です。
時刻ズレを発見した場合には、速やかに復旧計画を立てましょう。
時刻ズレを発見したときにすべきこと
以下のようなポイントを整理する必要性があります。
- 時刻ズレにより、既にトラブルが発生していないか
- 時刻ズレが生じているサーバを全て洗い出したか
- 時刻ズレの状況は、サーバ側の「時刻が遅れている」か「時刻が進んでいる」か (あるいは仮想基盤上のゲストの場合、ホストと時刻同期されているか、等)
- 時刻ズレが生じた原因が明確か
サーバ側の「時刻が遅れている」よりも「時刻が進んでいる」方が、仮に一気に時刻修正してしまった場合には時刻が戻る(逆進する)ので危険なケースが多いです(一概には言えませんが)。
また「時刻ズレの原因」も正確に把握すべきです。NTP設定自体が漏れていた、設定していたがNTPサーバと正常に通信できなくなっていた、等。どこをどう直せば時刻同期できるようになるのかを明確にすることが重要です。
復旧計画の立案
以下のようなポイントを整理する必要性があります。
- 基本的な復旧手順の確立
- 制約事項の整理
- 復旧計画の確定
順に説明します。
1. 基本的な復旧手順の確立
まず「時刻ズレの原因」に応じ、基本的な復旧手順を確立します。NTP設定やネットワーク設定の見直しなどです。サーバの再起動やNTPサービス(chrony)の再起動が必要か、等も整理しておきます。
手順確立のため使用できるテスト機があれば、先に試しておきましょう。
2. 制約事項の整理
焦って復旧方法を間違えると、さらに大きなトラブルに発展する可能性もあります。適切な復旧方法を選ぶため、例えば以下の優先度順で状況を整理します。
もちろん、影響を受けるデータやサービスがそもそも無い場合は、気にせず復旧させてしまえば良いです。
a. 時刻修正のために、対象のサーバやサービス(業務アプリ等)を停止可能か
停止可能な場合は、まずサーバやサービスを停止してから安全に復旧作業を開始する計画を立てます。これにより、サービスと関連するデータやプロセスが時刻修正による影響を受けないことを担保できます。
停止不可の場合は、次の項目を確認します。
b. 対象のサーバやサービス(業務アプリ等)は、稼働したまま時刻を一気に修正(step)しても問題が無いか
問題が無い場合(時刻を正確に扱わないシステムの場合)は、サーバやサービスを稼働させたまま一気に時刻修正する計画を立てます。
時刻修正が逆進かどうかもここで考慮します。サーバ側の「時刻が遅れている」場合は、一気に時刻修正するとサーバ上の時刻が急に進みます。逆に「時刻が進んでいる」場合は、一気に時刻修正するとサーバ上の時刻が急に戻ります。使用している業務アプリ等で不都合が無いかを慎重に判断します。
問題がある場合は、次の項目を確認します。
c. 対象のサーバやサービス(業務アプリ等)は、稼働したまま時刻をゆっくり修正(slew)すれば問題ないか
問題が無い場合は、サーバやサービスを稼働させたままゆっくり時刻修正(slew)する計画を立てます。
時刻修正の「ゆっくり」の程度はここで考慮します。chronyの場合、chrony.confのmakestep行をコメントアウトすることで、次回のchronyサービス起動時のstepモードでの時刻修正を回避でき、その後slewモードで時刻が修正されます。slewモードの時刻修正の速度(maxslewrate)のデフォルト値は83333.333 ppmで、これは「1秒の時刻ズレを最速12秒間で修正」するものです。さらにゆっくり修正したい場合はmaxslewrateを小さくします。詳細はこちらの記事にまとめてあります。
なお、ゆっくり時刻修正することですら問題がある場合は、そもそも現実的に復旧計画を立てられる状況にないので、再度サーバやサービスの停止可否から調整し直しましょう。
3. 復旧計画の確定
上記で整理した、復旧手順や、サーバ/サービスの停止可否、一気に時刻修正(step) or ゆっくり時刻修正(slew)を考慮して復旧計画を確定します。
一気に時刻修正(step)しても良ければ、正常に時刻同期ができるよう対処すれば良いだけです。
c.のゆっくり時刻修正(slew)する場合には、本記事の冒頭に記載したような手順が必要です。
なお、復旧すべき対象サーバが複数ある場合には、相互に連携する機能の有無を考慮し、対処タイミングを検討します。
上記により復旧計画を立案できたら、実行しましょう。
(ケースごとに手順が異なるので、本記事の説明はここまでです)
まとめ
本記事では、時刻ズレを安全に復旧する方法として、復旧手順の一例と、復旧計画の策定までの流れをまとめてみました。
