Linuxサーバ での 参照先 NTPサーバの選び方

最近久々にNTPのセットアップを変えたので、その時のことを 忘れないように書いておく。

戦略

ネットワーク上で同期をとりながら動いているLinuxサーバ群が正確に時間同 期する必要があるのは説明する必要はないだろう。サテライトサーバ(中心と なるサーバを参照しながら、それを中心に動く)は単純にセンターサーバにあ わせれば良い。問題はセンターサーバが、どう正しい時間を得られるかだ。

ntpは複数タイムサーバを参照しながら、正確に時間を同期させる。参照して いる複数のタイムサーバすべてが使われているわけはない。時間同期の参照先 として良い安定しているサーバ群をクラスタとして認識している。ここでは選 び方を議論しているのでNTPのクラスタという概念までは説明しないが調べて おくとNTPに対するより深い理解につながるだろう。

さて、精度を保とうとするとNTPは3つのタイムサーバを参照するのが良い。理 由は参照先に時間のずれがあった場合、2つだけだとどちらが悪いのか判断つ かないからだ、だから3だとわかる、といえば簡単にイメージしてもらえると 思う。実はこれは嘘ではないが、あまり本当でもない。実際にはもっと複雑な 計算をしている。詳細な理由は省くが、安定している3つ以上のタイムサーバ を参照するとこちらも安定して良くなる。

サーバの参照先の性質が違い、各々のサーバがネットワークに依存性がなく、 かつ安定しているサーバを選ぶのが一番安全だと言われている。なぜならば、 どこかのシステムやネットワークがダウンした時でもNTPが参照先を見つける ことができるようにである。

1つはネットワーク的に一番近いはずであるISPが提供しているntpサーバ、次 が今日本で一番安定していると言われているmfeedサーバ、最後はたくさんの タイムサーバを用意しているringサーバを選ぶ。公開している適切なntpサー バをまずは3つ選ぶ。2005年の夏なら、これがスタンダードな方法だろう。も ちろんこれは状況によって変化するので、その点は注意して欲しい。

2006年9月現在ではntp.nict.jpも選択肢の1つである。

大きめのドメインでの運用を考えるなら4つめを加えるべきだろう。万が一何 かの拍子で他のサーバ1つが参照できなくなったり、あまりにもdelayやjitta などが大きくなって参照に適さなくなった時のバックアップとして有効だ。見 つからない場合はISP、mfeed の優先順でもう1つを選んで入れよう。ここでは ISPのタイムサーバをもう1 つ加えて4とした。4つより設定しても、それはオー バースペックなので再考した方が良いだろう。

万が一、ISPがntpサーバを用意していない場合は、mfeedを2つ入れよう。 mfeedはIXと呼ばれる各ISPが接続交換しているポイント上に直接つながってい る。日本でこれ以上の優れたネットワーク環境はないというぐらいの接続場所 に直接つながっている。一方でringの場合、通常のISPやネットワークに接続 している所からデータが来るので、(偶然に近いネットワークでない限り)IX上 にあるmfeedよりもネットワーク的に遠い。よってネットワークトポロジーか ら考えるとring よりもmfeed の利用を勧める。

/etc/ntpd.conf

/etc/ntpd.confの例を載せる。

server ntp-tk01.ocn.ad.jp   # OCNネットワークユーザのみ
server ntp-tk02.ocn.ad.jp   # OCNネットワークユーザのみ
server ntp1.jst.mfeed.ad.jp # ntp1,ntp2,ntp3のうちの一つ
server ntp.nict.jp          # ラウンドロビンで選択される (2006-09-16 変更)

LAN内でのIPv6環境との影響でntp.nict.jpとうまく接続できない場合がある。 ntpq -pとすると、次のようになるはずである。

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp-tk01.ocn.ad 202.234.233.105  3 u   15   64    1    3.296    1.231   0.004
 ntp-tk02.ocn.ad 203.139.161.118  3 u   14   64    1    3.485    1.329   0.004
 ntp1.jst.mfeed. 210.173.160.86   2 u   13   64    1    3.597    0.767   0.004
 2001:2f8:29::ff .INIT.          16 u    -   64    0    0.000    0.000 4000.00
これはntp.nict.jpの問い合わせに対しDNSがIPv6アドレスを引いてしまうため である。このような現象が出た場合、次のように直接IPアドレスを設定するこ とで回避できる。 133.243.238.163, 133.243.238.164, 133.243.238.243, 133.243.238.243の 中から選ぶと良いだろう。

ntpdの同期状況を観察してみよう。

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-ntp-tk01.ocn.ad 202.234.233.104  3 u  168 1024  377    4.194   -0.326   0.977
+ntp-tk02.ocn.ad 202.234.233.104  3 u  942 1024  377    3.698   -0.558   0.339
*ntp3.jst.mfeed. fs-monntp2.mfee  2 u  408 1024  377    3.544   -0.265   0.220
+ring.nict.go.jp sntp1.nict.go.j  2 u  225 1024  377    5.386   -0.717   0.124
各サーバ名の前には"+"、"-"、"*"が表示されている。表示されるシンボルは 他にもあるが、大体がこの3の知っておけば良いだろう。

  • "*" : 現在、このタイムサーバとの同期を取っている。
  • "+" : "*"と共にタイムサーバのクラスタを形成している
  • "-" : クラスタには使われていない

    クラスタとは、お互い正しいかどうかを判断するための「相互監視」のための サーバだと思っておくと良い。この場合も3つあるので安定して使えているこ とがわかる。

    stratumは精度を保証している数値ではない。stratum 1からの階層レベルを意 味しているだけである。stratum のレベルは必ずしも高い必要はない。そのサー バまでのネットワークが安定していることが大切である。stratum のレベルが 混在していてもあまり問題はない。NTPが独自のアルゴリズムにより、各種の 状態から適切なサーバと思われる先を自動的に選択し参照する。単純なアルゴ リズムではないので、たぶんこのサーバが利用されるだろうという直感的予想 を裏切ることもしばしばである。なお参照先のみにアクセスしているのではな く、リストアップしたすべてのサーバとのデータをやり取りしている。NTPが 安定すると1024秒(約19分弱) に一回の頻度でデータをやり取りする。

    参考例では、すべてのサーバに関してネットワーク的には何も問題なくスムー ズにアクセスできていることがわかる。その差は2ミリ秒もない。ISP内にある OCN のタイムサーバよりIXに直結しているmfeedサーバへの方がネットワーク 的に速くアクセスできていることがわかる。その差はごくわずかなので神経質 になるほどの値ではない。またringのタイムサーバ(実際にはNICTのサーバ) は非常に時間のゆれが少なくなっている。実際の運用を考えた場合、どのタイ ムサーバと同期を取っても同じような精度で時間が同期できているだろう。 NTPサーバがどのサーバを優先して使うかはアルゴリズムによって決定するの だが、これだけサーバ間の差がないと、人間が見て、NTPがどのような選択を するかは直感的にはわからない。


  • キーワード: NTP 時間同期 インターネット タイムサーバ サーバの選び方

    目次へ

    すずきひろのぶ hironobu at h2np dot net 更新日: