RedhatLinux7から利用可能になった、時刻同期を行う機能の一つがChronyで、実際に導入している企業も増えているのではないでしょうか。
最近ではNTPの時刻同期にNTPDに代わり、CHRONYDを利用するところが増えていると思います。ただ、勘違いされやすいのが、NTPDに代わるサービスとして、NTPDよりもCHRONYDを利用したほうがいいという方がいますが、どちらも利用するにあたり使える機能、使えない機能があるので、状況に応じて導入するのがいいと思われます。
特にネットで検索すると色々と情報がでてきますが、実際にはどういった設定をしたらいいか分からないまま導入すると問題が発生する場合がありますので、しっかりと設定内容、機能差などをチェックしておく必要があります。
そして、参考になるのがRedHatのサイトです。
第18章 chrony スイートを使用した NTP 設定 Red Hat Enterprise Linux 7 | Red Hat Customer Portal
まず、Chronyに関する概要です。
Chrony は、ユーザースペースで実行するデーモンである chronyd と、chronyd を調整するコマンドラインプログラムである chronyc で構成されています。常時接続でない、または常時電源が付いていないシステムでは、ntpd を使ったシステムクロックの調整は、比較的時間がかかります。これは、多くの小さな修正がクロックのずれと補正の観測に基づいてなされるためです。
温度変化はシステムの電源を入れる際に大きくなる場合がありますが、これはハードウェアクロックの安定性に影響します。調節はシステムの起動のほんの数千秒以内に始まりますが、正確性についての許容範囲の幅としては、機器が温まっている場合の再起動では 10 秒、または要件や操作環境、およびハードウェアによっては数時間の時間がかかる可能性もあります。chrony は、ntpd とは異なる NTP プロトコルの実装で、システムクロックをより迅速に調整することが可能です。
Chronyを利用するメリットとしては、ntpd とは異なる NTP プロトコルの実装で、システムクロックをより迅速に調整することが可能という点でしょうか。
そして、ntpd と chronyd の違いについてです。ntpd と chronyd の大きな違いの 1 つは、コンピューターのクロックを管理するために使われるアルゴリズムにあり、chronyd が ntpd よりも優れている点は、以下のとおりとあります。抜粋です。
●chronyd は外部の時間参照が断続的にアクセス可能な場合でも機能しますが、ntpd が機能するには、規則的な時間参照のポーリングが必要になります。
●chronyd はネットワークの混雑が長時間にわたる場合でも機能します。
●chronyd のクロックの同期は通常より高速で、時間の正確性もより高いものです。
●chronyd は、水晶振動子の温度変化などによってクロックのレートが突然変更しても素早く適応します。一方、ntpd の場合は、落ち着くまでに長時間かかる場合があります。
●chronyd はデフォルト設定では、他の実行中のプログラムを乱さないように、クロックがシステム起動時に同期された後は、時間を更新しません。ntpd も時間を更新しないように設定できますが、クロックの調整に異なる手段を用いる必要があり、これは不利益となる面があります。
●chronyd は Linux 上のクロックのレートを幅広い範囲で調整できるため、たとえば仮想マシン上など、壊れたクロックもしくは不安定なクロックのあるマシン上でも操作が可能になります。
chronyd はデフォルト設定では、他の実行中のプログラムを乱さないように、クロックがシステム起動時に同期された後は、時間を更新しないそうです。このあたりの考え方はちょっと調査が必要ですね。実際に時間がズレるというケースがありそうですが、どうなるんでしょうかね。定期的にポーリングをかけないのはちょっと不安ですよね。 続いて、chronyd では可能で、ntpd ではできない点は、以下のとおりです。抜粋です。
●chronyd は、時間修正の方法が手動での入力のみという分離したネットワークのサポートを提供します。たとえば、管理者がクロックを見ている場合などです。chronyd は、異なる更新で修正されたエラーを見てコンピューターが時間を進めたり遅らせたりするレートを予測し、これを使ってコンピュータークロックを調整することができます。
●chronyd は、コンピューターの電源を切った際に時間を維持するハードウェアクロックを進めたり遅らせたりするレートを計算するためのサポートを提供します。システムが起動して、リアルタイムのクロックから取ってきた時間の調整された値を使ってシステム時間を設定する際に、このデータを使うことができます。このガイドの執筆時点でこれが可能なのは、Linux のみです。
続いて、ntpd では可能で chronyd ではできない点は、以下のとおりです。抜粋です。
●ntpd は完全に NTP バージョン 4 (『RFC 5905』) をサポートします。これには、ブロードキャスト、マルチキャスト、manycast のクライアントおよびサーバー、さらに孤立モードが含まれます。また、公開鍵の暗号化に基づく特別の認証スキームもサポートします (『RFC 5906』)。
●chronyd は NTP バージョン 3 (『RFC 1305』) を使用します。これは、バージョン 4 と互換性があります。
●ntpd には多くの参照クロック用のドライバーが含まれていますが、chronyd は gpsd などの他のプログラムに依存して参照クロックからデータにアクセスします。
注意なのは、chronydはNTPバージョン3を利用するということでしょうか。上記のような違いがあることを知ったうえで、chronyの導入を検討したほうがいいかもしれないですね。 ここまでは以前も紹介しましたが、ここからは意外と知らないchronyの誤ったうるう秒対策について説明します。
それは、maxslewrate、smoothtimeはNTPサーバ対策ということです。 ネットでLinux chrony slew うるう秒対策、などと検索をすると、以下の設定をしておけば大丈夫とあります。
leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001 leaponly
そして、それを見た人がさらに参照してブログ記事などを作成するので、誤った情報が拡散されることになります。上記設定はうるう秒対策であることは間違いありませんが、Red Hat Linuxのサイトではより分かりやすく、うるう秒対策の設定について説明されています。
Resolve Leap Second Issues in Red Hat Enterprise Linux
Resolve Leap Second Issues in Red Hat Enterprise Linux - Red Hat Customer Portal
ブログは参考になりますが、誤った情報や誤解を招く内容が書かれているケースがあるので注意が必要です。
