web-dev-qa-db-ja.com

NTPサーバーアーキテクチャ

複数のLinuxボックスを実行している仮想環境があり、すべてのntpアーキテクチャを管理する方法を計画しています。
「ntp.conf」ファイルに2台のサーバーを配置しても意味がない限り、クライアントが指すntpサーバーは1台または3台以上である必要があるため、最初のアプローチは1台のサーバーを使用することです。 「server1」は4つのパブリックサーバー、特にRHELサーバーを指し、他のボックス「server2」はserver1を指し、他のすべてのLinuxサーバーの下にはserver2を指しますが、このアーキテクチャで奇妙な動作が見られます。一部のサーバーがserver2とそれらの間で非同期になり、server1とserver2が完全に同期されない場合もあります。
私の最初の質問は、なぜそれが起こっているのかということです。
次に、同じserver1がパブリックntpサーバーを指し、次に3つのサーバー、「server2」、「server3」、「server4」がserver1を指し、他のすべてのマシンの下にある別のアーキテクチャを考え出しました。サーバーへ2-4。
このアーキテクチャによって、すべてのネットワーク内の同期が改善される可能性はありますか？
それとも、同期間で同じパフォーマンスになるでしょうか？
これをアーキテクチャ化するための最良の方法は何でしょうか？

編集済み

Server1からのntpq -pの出力は次のとおりです。

remote          refid      st t when poll reach   delay   offset  jitter
=========================================================================
*Time100.Stupi. .PPS.       1 u  317 1024  377  182.786    5.327   3.022
LOCAL(0)        .LOCL.     10 l  46h   64    0    0.000    0.000   0.000

そしてここにそのntp.conf：

# For more information about this file, see the man pages
# ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), ntp_mon(5).

driftfile /var/lib/ntp/drift

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.rhel.pool.ntp.org iburst
server 1.rhel.pool.ntp.org iburst
server 2.rhel.pool.ntp.org iburst
server 3.rhel.pool.ntp.org iburst
#broadcast 192.168.1.255 autokey        # broadcast server
#broadcastclient                        # broadcast client
#broadcast 224.0.1.1 autokey            # multicast server
#multicastclient 224.0.1.1              # multicast client
#manycastserver 239.255.254.254         # manycast server
#manycastclient 239.255.254.254 autokey # manycast client

# Enable public key cryptography.
#crypto

includefile /etc/ntp/crypto/pw

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8

# Enable writing of statistics records.
statistics clockstats cryptostats loopstats peerstats sysstats rawstats

### Added by IPA Installer ###
server 127.127.1.0
fudge 127.127.1.0 stratum 10

3つのクライアントの出力は次のとおりです。

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u    1   64    1    1.090   -0.138   0.036


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u 1035 1024  377    1.117   -1.943   0.530


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*server1         172.16.29.21     3 u   32   64    1    0.902    1.788   0.140
linuxredhatntpntpd
6
Edgar Sampere

ご使用の環境での時間管理の重要度によっては、server1を単一障害点にしたくない場合があります。メンテナンスや修理のために長期間オフラインにする必要がある場合、そのピアは同期を停止します。そこからはすべて下り坂です。

Server1、server2、server3、server4をすべて4つまたは5つのインターネットピアに同期させないのはなぜですか。次に、内部ネットワークはこれらのシステムを参照できますか？

従来の通念では、クォーラムに必要なのは3であると言われていますが、少なくとも1つが偽のティッカーと判断されるかオフラインになることを許容する必要があります。

参照してください; 5.3.3。アップストリームタイムサーバーの数量

さらに、現在の構成の奇妙さと問題について言及します。関連するホストのntpq -pの出力を確認すると便利です。

9
Aaron Copley

2台のサーバーが役に立たないというのは厳密には真実ではありませんが、 Best Current Practices RFCドラフト では最低でも4台を推奨しています。 NTPの交差アルゴリズムは、サーバーのnumberのクォーラムだけでなく、サーバーの時間のqualityにも依存します。戻る-そしてあなたはそれを予測することはできません。ですから、多ければ多いほど良いのです。 最大10個のアップストリームNTPサーバー でも問題ありません。

アーロンが述べたように、提案されたサーバー1〜4はすべてアップストリームNTPサーバーを指し、内部システムは4つすべてを指している必要があります。サーバー1〜4は相互にピアリングすることもできます（対称モードで）、ただし、これは厳密には必須ではありません。

アーキテクチャのどの時点でも、単一のサーバーを介してNTPを集中させてはならない理由を理解することが重要です：NTP冗長性だけでなく精度（NTPドキュメントの アルゴリズムの説明 を参照してください。理由を説明しています）。 'これについてもっと書いた 他の場所 、 アーキテクチャの提案 を含む。）

6
Paul Gear