chronyとsystemd-timesyncd – NTPクライアントの違いは何ですか？
どういうわけか、古い質問に完全に基づいていない "ntpd対systemd-timesyncd-信頼性を実現する方法NTP同期？" 、私は質問したいNTPclientの観点からのchronyとsystemd-timesyncdの違い。
Systemd-timesyncdは多かれ少なかれ最小のntpクライアント実装であるのに対し、chronyは本格的なNTPデーモンソリューションであり、NTPクライアントが含まれている場合があります。
Ubuntu Bionic Beaverリリースノート は次のように述べています。
単純な時刻同期には、基本システムにsystemd-timesyncdがすでに付属している必要があります。 Chronyは、タイムサーバーとして機能する場合、またはアドバタイズされたより正確で効率的な同期が必要な場合にのみ必要です。
最小限のプリインストールツールを使用してこの仕事をするのが好きで、systemd-timesyncdが私のユースケースで仕事をするのは確かですが、それでも興味があります。
- 精度の点で、2つの間の実際の違いは何ですか？
- 効率の違いは何ですか？
- NTP clientとしてのchronyのユースケースとも呼ばれる「単純でない」時間同期は何ですか？
systemd NEWSファイルでのsystemd-timesyncdのアナウンス は、このツールとChronyやそのようなツールとの違いを説明するのに役立ちます。 （強調鉱山）：
新しい "systemd-timesyncd"デーモンがネットワーク全体でシステムクロックを同期するために追加されました。 SNTPクライアントを実装しています。 NTP実装（chronyなど）またはNTP参照サーバークライアント側のみを実装し、完全なNTP複雑さ、に煩わされることはありません。1つのリモートサーバーからのクエリ時間とローカルクロックの同期のみに焦点を当てています。NTP=ネットワーククライアントにサービスを提供するか、ローカルハードウェアクロックに接続する場合を除いて、この単純なNTPクライアントは、ほとんどの場合適切ではありません。インストール。[...]
このセットアップは、サーバー群のほとんどのホストの一般的な使用例です。それらは通常、ローカルNTP=サーバーから同期されます。これらは、ハードウェアを含む可能性のある複数のソースから同期されます。systemd-timesyncdは、その一般的な使用例に対して使いやすいソリューションを提供しようとします。
特定の質問に対処しようとしています：
精度の点で、2つの間の実際の違いは何ですか？
複数のソースから同期データを取得することで、より高い精度が得られると思います。これは、systemd-timesyncdでサポートされているユースケースでは特にありません。ただし、信頼できる内部ネットワークに接続されている中央のNTPサーバーから同期データを取得するためにそれを使用している場合、複数のソースを使用することは実際にはそれほど重要ではなく、単一のソースから高い精度が得られます。
ローカルネットワークの同じデータセンターにある信頼済みサーバーからサーバーを同期している場合、NTPおよびSNTPは事実上存在しません。NTPはRTTを考慮に入れて時間測定を行うことができますが、RTTが非常に小さい場合はそれほど有益ではありません。高速なローカルネットワークと近くのマシン。使用しているソースを信頼できる場合は、複数のソースは必要ありません。
効率の違いは何ですか？
単一のソースから同期を取得することは、複数のソースから同期を取得するよりもはるかに簡単です。これは、どのソースが他のソースよりも優れているかを判断したり、複数のソースからの情報を組み合わせたりする必要がないためです。アルゴリズムははるかに単純で、単純なケースではCPU負荷が少なくて済みます。
NTP clientとしてのchronyのユースケースとも呼ばれる「単純でない」時間同期は何ですか？
これは上記の引用で対処されていますが、いずれにしても、これらはsystemd-timesyncdでカバーされていないChronyの使用例です。
- 実行中NTPサーバー（他のホストがこのホストを同期のソースとして使用できるようにするため）;
- NTP複数のソースから同期情報を取得します（これは、ホストがインターネット上の公開サーバーからその情報を取得するために重要です）。
- ローカルクロックから同期情報を取得します。これには通常、衛星から正確な時刻情報を取得できるGPSデバイスなどの専用ハードウェアが含まれます。
これらの使用例では、Chronyまたはntpdなどが必要です。
他の答えが正しく述べているように、chronyはNTP and systemd-timesyncd SNTP。
タイムサービスクライアントの観点から：
SNTPは実装がはるかに簡単なプロトコルです。
NTPは、時間ごとの段階的な増分/修正を可能にします。 NTP=の主な利点の1つは、より正確な時間を取得するために回答のRTTも考慮することです。
から https://www.meinbergglobal.com/english/faq/faq_37.htm
フル機能のNTP=サーバーまたはクライアントは、非常に高いレベルの精度に達し、さまざまな数学的および統計的方法とスムーズなクロック速度調整を使用することにより、可能な限り急激なタイムステップを回避しますが、SNTPは精度と信頼性の要件がそれほど要求されない単純なアプリケーションに推奨されます。ドリフト値を無視し、システムクロック調整方法の単純化された方法（多くの場合、単純な時間ステップ）を使用することにより、SNTPは、完全なNTP実装。
SNTPは、はるかに単純なアプローチを採用しています。 NTPアルゴリズムの複雑さの多くが削除されます。多くのSNTPクライアントが時間を歪めるのではなく、時間をステップします。これは、単純なタイムスタンプが必要な多くのアプリケーションにとっては問題ありません。さらに、SNTPは複数のNTP=サーバーを監視およびフィルタリングする機能。多くの場合、1つのサーバーに障害が発生した場合、リスト内の次のサーバーが使用される単純なラウンドロビンアプローチが使用されます。
From https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp から
NTPはSNTPよりもはるかに正確で正確であるため、ほとんどのエンタープライズアプリケーションで事実上の勝者となっています。一方、SNTPはシンプルであるため、IPカメラ、DVR、一部のネットワークスイッチなどに適しています。これらのタイプのハードウェアには、より複雑なプロトコルを処理するための処理リソースが不足していますが、接続されたデバイスがますます強力になるにつれて、状況が変わる可能性があります。
SNTPの主な弱点の1つは、Network Time Protocolがデフォルトで行うように、複数のソースから時間を取得することで、より正確にすることができないことです。
ハイパーバイザーとNTPデーモンの両方が=を変更しようとしている場合、SNTPの実装がNTPは仮想化にあるVM時間。特に、いくつかの設定ミスで時間に同意しないと、両方がアクティブになる可能性がありますが、大きな問題が発生する可能性があります。（有能なシステム管理者は、時間と同期するためのアクティブな方法を1つだけ維持しますが、両方とも構成エラーによってアクティブになっている可能性があります）。
追伸systemd-timesyncdは、systemdを使用しない場合の推奨代替手段ではありません。
chronyはntpdのフォーク形式ではありませんが、ゼロから実装されます。フルNTPv4プロトコル（ RFC5905 ）のclientおよびserverモードの両方を実装します。エンタープライズグレードのユーザーでは、Red Hat（RHEL 7以降）やSuSE（SLES 15以降）などの従来のntpdからchronyへのトレンドの切り替えが見られます。
systemd-timesyncdは、SNTPプロトコル（ RFC43 ）clientモードのみを実装します。したがって、複雑な使用例はsystemd-timesyncdではカバーされていません。たとえば、SNTPは、NTPがデフォルトで行うように、複数のソースから時間を取得することによって、より正確にすることができません。その結果、systemd-timesyncdは、chrony。