Unixのヒント。 NTP コマンド
ITworld.com – Unix に関する質問をお寄せください！
その他の Unix のヒントやトリックを見る
先週のコラムでは、NTP (Network Time Protocol) と高精度な時間管理の概念について紹介しました。 システム管理者が管理するシステム上でかなり正確な時間を維持するのに役立つ数多くのコマンドが存在しますが、最も明白なものは非常に限られています。 その結果、ほとんどのネットワークでシステム時刻の大きな不一致に悩まされています。 以下に示すような時差 (実際のネットワークから取得) は珍しくありません:
host01: Thu Oct 14 10:50:23 EDT 2004
host02: Thu Oct 14 10:43:53 EDT 2004
host03: Thu Oct 14 10:41:52 EDT 2004
host04: Thu Oct 14 10:50:13 EDT 2004
host05: Thu Oct 14 10:33:59 EDT 2004
host06: Thu Oct 14:48:17 GMT 2004
host07: Thu Oct 14 10:52:04 EDT 2004 *
host08: Thu Oct 14 10:52:33 EDT 2004
host09: Thu Oct 14 10:49:55 EDT 2004
host10：10月14日（木） 10:33:20 EDT 2004 *
host11: Thu Oct 14 10:51:22 EDT 2004
これら 11 の連続ポーリングされたシステム内では、報告時刻にかなりのばらつきがあることがわかります。 ポーリングは数秒のスパンで行われましたが、時間差は数秒よりかなり大きくなっています。 実際、最も早く報告された時間と最も遅く報告された時間の間には、18分44秒の差があります。
これらのようなシステムをより近い時間に強制するために、システム管理者はいくつかのコマンドのいずれかを使用しますが、その成功の度合いはさまざまです。
日付コマンド
システム管理者が日付と時間を設定できる日付コマンドは、システムの時間を修正する最も明白なコマンドですが、システム管理者がかなり正確な時間基準を持っているかどうかに依存します。 また、このコマンドは一度に1つのシステムで実行されます。 dateコマンドを使って2つのシステムを同期させる場合、システム管理者はシステムの時刻を互いに数秒以内の誤差に近づけることはまずないでしょう。 同期が重要な場合、dateコマンドは明らかに選択すべきコマンドではありません。
下図のようなループでシステム管理者が date コマンドを発行した場合、システム時刻は上図よりも近くなりますが、ループが完了するのにかかるのと同じだけ秒単位で変化し続けることになります。
for host in `cat host_list`do ssh $host "date 10141045"done
日付コマンドは、明らかにシステムの同期に最小限の役しか立ちません。 たとえ毎日数秒のオーダーであっても、時間の増減が起こりがちなシステム クロックは、時間のギャップをすぐに再び広げてしまいます。 さらに、他のタイムゾーンで設定されているシステム、たとえば上記のリストでGMTとして時刻を報告しているシステムでは、dateコマンドを使用した場合、時刻が何時間もずれてしまうことになります。
rdateコマンド
ネットワーク上のクロックの同期にはるかに適したrdateコマンドでは、システム管理者が自分のネットワークにアクセスできるシステムを1つ、おそらく他のシステムの時間基準として使用するためにかなり正確な時間を保持しているシステムを選択する必要があります。 結局のところ、各 rdate コマンドは、そのコマンドが実行されたときに、参照サーバー上の時刻に同期するので、このループが完了するために必要な時間は、有害な影響を与えません。
for host in `cat host_list`do ssh $host "rdate timekeeper"done
さらに、rdate コマンドはターゲット システム上のタイムゾーンを上書きしません。 コマンド ラインで提供される値に文字通り時間を設定するのではなく、rdate はタイム ゾーンに依存しない時間データを要求します。 言い換えれば、GMT を使用するシステムで “rdate” を実行すると、GMT システムの時刻は正しく設定されます。
rdateコマンドは、一般にシステムの起動時または cron で 1 日または 1 時間に 1 回実行されて、LAN 上のシステムの時刻を合わせます。 先に示したような無秩序なシステム クロックと比較すると、これは大きな改善です。 しかし、rdateでクロックをリセットされた各システムから見ると、非常に珍しいことが起こる可能性があります。 rdateコマンドを実行するたびに、時計は時間を進めたり戻したりすることができるのです。 この動作は、時間に敏感なイベントの非常に奇妙な解釈につながる可能性があります。
NTP コマンド
NTP には、date コマンドと rdate コマンドに対して明らかにかなりの利点があります。 たとえば、NTP は、システム クロックを非常に正確に同期させ、必要な調整をスムーズに行う方法を提供し、rdate などのコマンドがしばしば引き起こす時間のジャンプを回避します。 ntpdate コマンドは、rdate コマンドと同じようにシステム時刻を設定します (つまり、rdate コマンドと同じようにシステム時刻を設定します)。
The ntpdate command
一般に ntpdate コマンドは、rdate コマンドと同様に、システムの起動時、要求時、または cron によって定期的に使用され、rdate と同様の方法で「その場」ベースで時間を同期させます。 しかし、ntpdate コマンドには、rdate に対して 2 つの非常に重要な利点があります。
まず、ntpdate は、ネットワークからアクセスできる信頼できるタイムキーパーだけでなく、NTP サーバーも参照します。 NTP サーバーは一般に NTP 階層 (そして、最終的には高精度の原子時計) に接続されているので、単に優れたクロック チップを持っているどのサーバーよりも正確であることがほぼ保証されています。
もうひとつは、ntpdate は多数の時間ソース (すなわち、複数の NTP サーバー) から多数の時間サンプルを収集し、最も正確に見える時間を選択することができます。 したがって、ntpdate コマンドは、rdate で使用するために選択されたものよりも正確である可能性が高い時間ソースを参照するだけでなく、多数のそのようなシステムを参照し、高度な選択プロセスを適用します。
ある ntpdate コマンドは、次のようなものです。6.15.28
14 Oct 10:52:41 ntpdate: adjust time server 129.6.15.28 offset -0.003350 sec
実際、ntpdate コマンドがシステムにインストールされていれば (ほとんどの Solaris システムでは /usr/sbin/ntpdate) 、今まさにその ntpdate コマンドを使ってみるとよいでしょう。
別の方法として、次のような ntpdate コマンドを試すこともできます:
# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9
14 Oct 14:57:41 ntpdate: adjust time server 216.200.93.8 offset 0.015733 秒
この場合、複数の NTP サーバーが照会されます。
The NTP Daemon
ntpdate コマンドは rdate よりも一段と優れた時間制御を提供しますが、NTP デーモンは精度と信頼性を最大限に高める高度なアルゴリズムで ntpdate より大きなステップを踏みます。
NTP デーモンは、逐次近似プロセスによりシステム クロックをスムーズに同期させる洗練されたアルゴリズムを提供します。 デーモンが長く実行されればされるほど、システム時刻はそのソースの時刻とより近くなります。
精度の高いレベルに到達するまでには、数分から数時間かかるかもしれませんが、いったん到達すると、システム上の時間の信頼性は驚くほど正確なものになります。 とはいえ、NTP の時間の正確さは、最終的には、NTP が参照する時間ソースの正確さに結びつきます。 各NTPサーバーは、利用可能な最良のタイムソースと伝送路を使用してUTC（協定世界時）への同期を試みる。 参照するサーバーのセットが互いに近接していない時刻を送信した場合、NTPはこれらのタイムサーバーの1つ以上が故障しているとみなし、それらを割り引きます。
NTP を初めて使用する人は、NTP デーモン プロセスを実行しても、システムが NTP サーバーになるとは限らないことに注意する必要があります。 NTP が有効なシステムがクライアントの役割を果たすかサーバーの役割を果たすかは、そのシステム上のデーモンの設定ファイルによって決まりますが、これは来週のコラムで検証します。 NTP コマンド」は、ITworld に掲載されたものです。