ntpについて質問です ntpq -p の結果について


以下はntpq -pの結果です


remote refid st t when poll reach delay offset jitter
===========================================================================
+xxxxxxxx xxx.xxx.xxx.xxx 8 u 85 128 373 0.159 121.411 3.043
*xxxxxxxx yyy.yyy.yyy.yyy 8 u 59 128 377 0.187 122.618 2.626


通常であれば上記のようにwhenの値がpollよりも小さいのですが
時折,以下のようにwhenの値がpollの値を大きく越えてしまう(104m)
場合があります


remote refid st t when poll reach delay offset jitter
===========================================================================
+xxxxxxxx xxx.xxx.xxx.xxx 8 u 104m 512 300 1.834 236.726 14.426
*xxxxxxxx yyy.yyy.yyy.yyy 8 u 792 1024 377 5.846 348.096 24.042



①通常であれば,いつ最後のバケットを受信したかを示す「when」の値は
 ポーリング周期「poll」の値を超えることは無いと考えておりますが
 この認識は正しいでしょうか

②上記の現象が発生する原因として,どのようなことが考えられるでしょうか

③また,原因を特定するためにntpログのどういった部分に着目すればよいでしょうか


質問は以上です。
どうぞよろしくお願いいたします。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2013/05/10 01:08:32
  • 終了:2013/05/17 00:09:13

ベストアンサー

id:vow No.3

ghost回答回数21ベストアンサー獲得回数92013/05/13 14:08:15

ポイント100pt

あー・・・参照先のサーバは同一機体の別I/Fでしたか。

まず念のため、送信と受信が別経路になる状態でのNTP運用は、原則として非推奨です。それぞれの経路の負荷がばらばらに変動する影響を受けるので、遅延の補償がうまくいかず精度が落ちやすくなります。ですので、とりあえずNTPについて言うなら、単にeth1だけ使うのがひとまずの正解だと思います。どうせ戻り経路が同じなのであれば、eth0を参照させておいても耐障害性は得られません。

で、問題のAからB:eth0の見え方については、これはNTP関係なしに本当にネットワーク構成自体の問題ですが・・・まずBの複数I/Fが何を意図していたのかわからないので何とも言い難いです。戻り経路が分離していない時点でロードバランスにはなってないし、管理ネットワークと公開系ネットワークを分けているにしても腑に落ちない。全く自動化していない冗長化もどき?

強いて現状のネットワーク構成が正しいことを前提として言うならば、「そもそもAからB:eth0に到達できていること自体が間違い」という結論しか出てきそうにない気がします。元々の意図がわかればもう少し何か言えることがあるかもしれません。

他1件のコメントを見る
id:vow

AからR経由でB:eth0に送信(だけ)できてしまっているのが最初から間違い(つまりA→RかR→B:eth0のどちらかが意図したものでない)なのかな、と。

逆にもしこれで冗長化のつもりなのだとしたら・・・これを冗長構成として運用するのはかなり面倒くさいような・・・と言いますか、実は冗長化のフリをしているだけで実際には何の役にも立ってないというひどいオチの可能性が。

2013/05/13 23:53:16
id:fujimasa1985

回答ありがとうございます
ネットワークの問題である可能性が高いと言うことで納得致しました

2013/05/17 00:07:15

その他の回答(2件)

id:TransFreeBSD No.1

TransFreeBSD回答回数654ベストアンサー獲得回数2632013/05/10 09:24:17

ポイント50pt

①「通常」がエラーのない状態をいうのであれば普通は超えません。

②whenがpollを超えるのはパケットが帰って来なかったからです。ntpdがパケットを送出できなかったか、行き帰りの途中でパケットが失われたか、が主な原因と思います。

③今回の場合、常時ではなく時折、それも片方だけなので、自ネットワーク以外のどこかでパケットロスしている可能性が高いと思います。ntpログよりICMPパケットが来ていないか確認してはどうでしょうか。

ntpqの出力結果についてですが、reachが前者は「373」後者は「300」となっています。
この数字は8進数で、2進数表記にすることで失敗したポーリングを表します。
「373」の2進数表記は「11111011」、3つ前が失敗しています。
「300」の2進数表記は「11000000」、過去6回連続で失敗しています。
pollの512×6=3072秒=51.2分ですが、それまでのpollが1024なら倍の102.4分、さらに次回までの512秒≒8.5分の途中ということで、7回前から104分と解釈出来ます。
#pollは2048→1024→512という遷移でも解釈できると思います。
参考:http://www.asahi-net.or.jp/~aa4t-nngk/ntpd2.html#utils_howto

この時以外でも「11111011」と失敗があること、もう一つの方は「377」とその間に全く失敗してないことなどを考えると、どちらかと言えば相手サーバ側の問題だと思います。
運が良ければICMPパケットが来ていて問題のノードはわかるかもしれません
しかし、ICMPパケットすら届かない可能性も高く、また問題のノードが分かったとしても、こちらが打てる手は、たぶんそのサーバを使わないという事しかないかもしれません。

id:fujimasa1985

reachについてよくわかっていなかったのでとても参考になりました

2013/05/13 01:11:27
id:vow No.2

ghost回答回数21ベストアンサー獲得回数92013/05/10 09:41:15

ポイント50pt

http://doc.ntp.org/4.2.6p5/ntpq.html
http://doc.ntp.org/4.2.6p5/debug.html

pollとwhenの解釈はあっています (ただし状況により数秒超える程度は通常稼働状態でもあります)。これは測定点が欠測あるいは品質不足により棄却になっている状態です。[reach] reach shift register が直近8回の測定状況で、(既に8回以上測定している場合) 値が 377 でない場合は測定が抜けています。

ありがちな原因としては

  • 参照先サーバが遠すぎる
  • 経路ネットワークの輻輳や非対称負荷
  • 参照先サーバないしローカルマシンの過負荷

などですが、一概には言えません。負荷状況やトリップタイムなどを観察してどれと相関があるか割り出していくことになります。

他1件のコメントを見る
id:fujimasa1985

peerstatsファイルについて分からなかったので調べてみました

http://jp.fujitsu.com/platform/server/sparcenterprise/manual/notes/pdf/ntpguide.pdf
のp41~42

時刻サーバとの同期状態の遷移を調べられるという解釈でよいでしょうか

2013/05/13 01:14:26
id:vow

正確に言うなら、実際に同期を行う前の、単にサーバから得ただけの測定値です。
その中から「一番もっともらしいサーバ」を選んで実際の同期に使うわけです。

普通のsyslogに出てくるのは、「一番もっともらしいサーバ」を選んだ後の、同期処理の具合だけなので、各サーバがそれぞれどういう応答をしているか、まではわからないのです。

2013/05/13 14:26:00
id:fujimasa1985

質問者から

QUWE2013/05/13 09:30:12

回答いただきどうもありがとうございます。
返答が遅くなってしまい申し訳ありません
問題の現象が発生した計算機が参照するntpの時刻サーバーは自ネットワーク内に存在しております。

自ネットワークの問題を疑って、いろいろ調べていました。


問題が発生した計算機を、計算機A
計算機AのNTPDが参照する時刻サーバを計算機Bといたします
(計算機Bもほかの時刻サーバを参照している。参照先が自ネットワークか否かは調べておりません)

計算機Aは以下に示す2つの経路で計算機Bへ時刻問い合わせを行っています
(時刻サーバは1つで、問い合わせに用いるルートが2つある)

1.ルートR(応答が返ってこないことが頻発するルート)

計算機Aのeth0を通って、計算機Bのeth0に問い合わせパケットが送られる
Aのeth0→ゲートウェイR(ルータ?)→Bのeth0

計算機Bのeth1を通って、計算機Aのeth0に応答パケットが送られる
Bのeth1→ゲートウェイL2(ルータ?)→Aのeth0

2.ルートL

計算機Aのeth0を通って、計算機Bのeth1に問い合わせパケットが送られる
Aのeth0→ゲートウェイL1→Bのeth1

計算機Bのeth1を通って、計算機Aのeth0に応答パケットが送られる
Bのeth1→ゲートウェイL2→Aのeth0


計算機Bから応答が返ってこない状態のときのパケットの送出状態をtcpdumpを使って調べてみました

以下が結果です

計算機Aのeth0から送られた問い合わせパケットは計算機Bのeth0に届いていました
しかし、計算機Bのeth1に応答のパケットが送られておらず、計算機Aは計算機Bからの応答を
受け取ることが出来ていませんでした

このことから計算機Bのntpdが、計算機Aに応答を送信していないのか
送信はしているが失敗しているのどちらかだと考えています

このときに、計算機Aから経路Rを通って計算機Bにpingを送出するとなぜか
上記の現象が解消してしまいます
(1度目のpingは時間がかかるか失敗するが2回目のpingはたいてい通る)


ネットワークの問題だと考えていますが
どうして問題でおきているのかわかっていない状態です。

id:vow No.3

ghost回答回数21ベストアンサー獲得回数92013/05/13 14:08:15ここでベストアンサー

ポイント100pt

あー・・・参照先のサーバは同一機体の別I/Fでしたか。

まず念のため、送信と受信が別経路になる状態でのNTP運用は、原則として非推奨です。それぞれの経路の負荷がばらばらに変動する影響を受けるので、遅延の補償がうまくいかず精度が落ちやすくなります。ですので、とりあえずNTPについて言うなら、単にeth1だけ使うのがひとまずの正解だと思います。どうせ戻り経路が同じなのであれば、eth0を参照させておいても耐障害性は得られません。

で、問題のAからB:eth0の見え方については、これはNTP関係なしに本当にネットワーク構成自体の問題ですが・・・まずBの複数I/Fが何を意図していたのかわからないので何とも言い難いです。戻り経路が分離していない時点でロードバランスにはなってないし、管理ネットワークと公開系ネットワークを分けているにしても腑に落ちない。全く自動化していない冗長化もどき?

強いて現状のネットワーク構成が正しいことを前提として言うならば、「そもそもAからB:eth0に到達できていること自体が間違い」という結論しか出てきそうにない気がします。元々の意図がわかればもう少し何か言えることがあるかもしれません。

他1件のコメントを見る
id:vow

AからR経由でB:eth0に送信(だけ)できてしまっているのが最初から間違い(つまりA→RかR→B:eth0のどちらかが意図したものでない)なのかな、と。

逆にもしこれで冗長化のつもりなのだとしたら・・・これを冗長構成として運用するのはかなり面倒くさいような・・・と言いますか、実は冗長化のフリをしているだけで実際には何の役にも立ってないというひどいオチの可能性が。

2013/05/13 23:53:16
id:fujimasa1985

回答ありがとうございます
ネットワークの問題である可能性が高いと言うことで納得致しました

2013/05/17 00:07:15
  • id:vow
    ああのんびり書いている間に(

    切り分けるには情報が足りてないので以下は確定ではなく憶測として捉えてください。jitterが揃ってかなり増加しているあたりからすれば、経路ネットワークの負荷、それも遠くのサーバ側ではなく目の前のローカル側の接続線が一番怪しい。一時的に片方のサーバだけがダメに見えることは、実運用では意外と簡単に単純な運の問題で起きることがあり、それだけでサーバ側のせいと言い切るのは若干早計です。このあたりの判断は二つのサーバが経路的にどれくらい離れているかにもよりますが。

    もし本気で追求するなら
    -LAN内の他のサーバを参照させて比較する
    -経路的にもっと近いサーバを参照させて比較する
    -なるべく違う経路で到達するサーバを参照させて比較する
    -それらの測定値と一緒に通信量などをグラフに引いて見比べてみる
    みたいな地道な作業になります。

    ホームユースの範囲内ではchronyの方が便利なことが多いと思うけど、あれはあれで癖があるからなー。
  • id:TransFreeBSD
    あー他の値見てなかった。早計でした(^^;
    jitterもですが、delayがかなり増加してますね。初期は0.1台なのが問題の頃は5台に。単位はmsでしたっけ?
    そう言われれば確かに自ネットワーク側が怪しいかもしれません。
    というか、delayが0.1台ってのはかなり早い気がします。もしかして自ネットワーク内にあるのでしょうか?

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません