NTP サーバ立ち上げまでの道
今回は Windows 2000 でクラスタシステムを導入時の設定ミスにより、タイム・サービス・リソースの導入が漏れてしまった。たまたま、２台のサーバの時間をチェックした時に約１分の違いを見つけ、フェールオーバ、フェールバックが発生した時のＤＢの動きを考えたときに、矛盾が生じることがわかった。 Microsoft社によると「WindowsNT 4.0 ドメインで Windows 2000 を使い、かつ Windows クラスタリングを使用するには、タイム サービス リソースをインストールする必要があります。（文書番号:JP279005）」となっていたのを気づかなかった。
もっとも、この文書が公開されたときには設定は既に終了し、本番稼働中だった。。。。。そこで！！ どうせ時間の同期が必要なら、日本標準時にできるだけ合わせてやる！！ と思い立った。
2003/2/13 追記
Window NT 4.0 ドメインで Windows 2000 Server SP3 を使用してクラスタリングを構成し、タイム サービス リソースをインストールしている時に、クラスタ間での時刻同期が行われなくなる場合があります。クラスタ リソースは 'Online' 状態のままです。
私の環境では見かけ上は、異常なく動いているように見えますが、クラスタ ログに下のようなエラーが出力されました。
Time Service <TimeService> : Creating resource.
Time Service <TimeService> : Failed to create notify port, status 1722. Stopped Listening...
2003/2/17 追記
現在では、Microsoft社より技術アナウンス等は出ておりません。
時間が合わなければフェイル・オーバした時に、 DB のレコードが消えてしまう可能性があるので、私は、タイム サービス リソース が動いていない方のノードに、Net Time コマンドで タイム サービス リソース が動いている方のノードの時間に同期を取るようなバッチファイルを作成し、タスク・スケジューラにて、４時間置きに起動して時間の同期を取っています。2003/4/12 追記
Microsoft社からPrivate QFE(Quick Fix Engineering) を出して頂ける事になりましたが､クラスタに関連する主要なモジュールの多くが影響を受けることが分かりました。また、今回の障害以外の修正も含まれています。その為､今回の障害対応以外の内容で障害が発生する可能性があります。また、Private QFE と言う位置付けの為､Windows 以外のアプリケーションの検証はされていません。
この修正は、Windows 2000 Server SP4 に含まれるそうです。（2003年、初夏に出荷されるようです。）
今回、障害が発生したサーバは主業務で使用しているため､信頼性の欠ける Private QFE の適用を見送り、SP4 の出荷を待つことにしました。
● 時刻基準サーバを立ち上げる
いろいろ調べたが、ＧＰＳ（汎地球規模・測位システム ：グローバル・ポジショニング・システム）から時刻を採取する方法、情報通信研究機構の標準電波ＪＪＹを受信して時刻を採取する方法等があったが、ビルのせいもあり、簡単にアンテナを屋外に設置できそうにない。もっと、お手軽に安く、また、自動で時刻合わせできる方法が無いか調べてみた。その中で、ＮＴＰ（Network Time Protocol）というプロトコルを利用して時刻を得る方法を見つけた。
● ＮＴＰについて
これは、ネットワーク上の時刻情報を提供する NTP サーバと時刻情報を受けて内部時計を合わせる NTP クライアントによって構成される。
NTPサーバは、時刻源となるセシウム原子時計に直結されたサーバ、 GPS を時刻源とするサーバ等の最も精度が高く UTC (協定世界時)に同期しているものから stratum （階層:ｽﾄﾚｲﾀﾑと読むらしい）1,2,3・・・・とランク付けされたツリー構造になっており、互いに階層の高い方から低い方へ時刻同期を行う仕組みです。（階層が低くなれば、それなりに精度が落ちてくるが、現実的にはあまり問題にならないと思う。）
階層化している理由として、１台のサーバにクライアントからの接続が集中すると、サーバの負荷が増え、応答時間も劣化する。そうなると時刻の精度も落ちる。このように階層化することによって、ねずみ算的に接続できるクライアント数が増えてくる。
Stratum 1 ・・・ 原子時計、ＧＰＳ等を時刻源にしているサーバ
↓
Stratum 2 ・・・ Stratum 1を時刻源にしているサーバ↓
Stratum 3 ・・・ Stratum 2を時刻源にしているサーバ
● ＮＴＰとＳＮＴＰ↓クライアントは複数台のサーバに接続できる。上位のサーバに障害が起きたり、時刻源が狂った場合、信用できない場合にも対応できるようになっている。
同一階層同士のサーバ間で時刻情報の交換を行って、時刻源の精度を上げることもできる。
RFC-1305 にて NTP Version3 について定義されている。 NTP は複数台のサーバから時刻情報をもらったり、同一階層同士で時間情報の交換を行うこともできる。
その為、昔のコンピュータは非力だったため、NTP の全てを実現することが難しかった。そこで、SNTP(Simple Network Time Protocol) が定義された。
RFC-2030 にて SNTP Version4 が定義されている。 NTP の機能を簡略化（１台の上位サーバにしか接続しない、同一階層同士の時刻情報交換を行わない、など）し、実装しやすくしている。NTP、SNTP とも共存できるように設計されているが、 SNTP は NTP の機能限定版なので階層の末端でのみ使用されることが推奨されている。
すなわち、SNTP クライアントまでの中間の Stratum は NTP サーバ、クライアントを使用する様にと言うことだ。
● 時間のずれの計算
- クライアント側から送信時間Ａ 測定し、送信する。
- サーバ側で受信時間Ａ を測定する。
- サーバ側で送信時間Ｂ を測定し、送信する。
- クライアント側で受信時間Ｂ を測定する。
（この時点で、クライアント側は、送信時間Ａ，Ｂ 、受信時間Ａ，Ｂ の４つの情報が集まった。）上記から、
受信時間Ａ − 送信時間Ａ ＝ パケットを運ぶ時間 ＋ 時刻のずれ
受信時間Ｂ − 送信時間Ｂ ＝ パケットを運ぶ時間 − 時刻のずれ
送受信の遅延時間が同一だと仮定すると
時刻のずれ＝（（受信時間Ａ − 送信時間Ａ ) − (受信時間Ｂ − 送信時間Ｂ )) ／ ２
となる。
送受信の遅延時間が同一ということはあり得ないが、遅延時間が小さければ問題はないと考えられる。よって、ネットワーク的に近いサーバを選択することが勧められる。
SNTP はパケットの往復時間を平均して遅延時間を算出しているが、NTP は統計的な揺らぎを考慮することで精度を高めている。
● サーバのモード
● 「NTP、SNTP のフォーマット」 へ
サーバ・クライアント・モード クライアントからサーバにリクエストを送り、時刻情報をもらうモード。
（一般的にはこのモードが使用される。）対称モード
（アクティブ・パッシブ）同一階層同士で時刻情報を交換し、互いの時間を調整するモード。（NTP のみ） ブロードキャスト・モード サーバが一方的に時刻情報を送りつけるモード。ＬＡＮなどの遅延時間が少ないネットワークで使用する。クライアント側にはあらかじめ、回線の遅延時間等を設定ファイル内に設定しておく。（NTP のみ）
● Windows の問題
WindwosNT4.0 、 Windows2000 、 Windows98 にフリーの SNTP サーバ、NTP クライアントを導入してみたが、同期を取った後、すぐに同期を取ると50〜100ms程度修正される場合が何度か発生した。回線の遅延時間かと考えたが決まって50〜100ms程度なので調査した結果、 Windows98 等ではタスク切り替え時間が54.9ms単位で発生するため、誤差が出る可能性があることがわかった。WindowsNT 系では発生していないように見えたが、確実なところは不明だった。
少々、不安ではあったが、Unix で NTP サーバを構築してみようと考えた。
Windows2000 で Linux
の様に時刻源のサーバに接続できなくても、複数のサーバに接続できたり、また、Drift File 等を使用して時間を自動で調整するソフトを見つけ切れませんでした。どなたかご存じないでしょうか？
（ほとんどのソフトが Drift File 等を使用せず、サーバに接続できなかったらそれっきりのようです。）
● Windows2000 での NTP サーバ立ち上げ （２００１／１２／２５ 追加）
いろいろと調べていたら、私の希望するような Windows2000 の NTP サーバを見つけました。
● クライアント(Windows) の設定 （２００１／１２／２７ 追加）
参考に、 Windows クライアントの設定方法を調べてみました。
● NTP.CONF の説明 （２００２／０１／０６ 追加）
ntp.conf の設定方法を調べてみました。
● Linux,Unix と Windows2000 Server のクロックについて （２００２／０１／０８ 追加）
Linux,Unix はハードウェア・クロックとシステム・クロックを持っており、システム・クロックは Boot 時にハードウェア・クロックを参照して設定し、その後は、システムクロックで動作する。
NTP ではシステム・クロックの進み方を遅くしたり、進めたりして時間を合わせている為、時間が戻ることはない。システム・クロックが進んでいる場合、進み方を遅らせることにより対応している。Windows 2K Server はハードウェア・クロックしか持っていない。時間の進み方はハードウェアに依存する為、時間の進み方を調整することができない。その為、時間が戻る場合がある。
時刻源サーバとして使用する場合は、Linux,Unix を使用しないと、時間の逆転が発生する可能性が非常に高く、データベース・サーバの時刻源として使用する場合、問題が発生する可能性が高いと考えられる。
私が調査した限りでは、Linux,Unix で時刻源サーバ (NTP サーバ) を構築することを推奨する。
＜参考URL＞
http://www.asahi-net.or.jp/~mu6k-ski/ntp.html
(コメント：一番最初に見た方がよいと思います。）
http://www.miz.nao.ac.jp/staffs/hisa/index.html#TRANS
文部科学省 国立天文台 地球回転研究系 水沢観測センター 佐藤克久
http://jjy.nict.go.jp/
独立行政法人 情報通信研究機構 日本標準時グループ
http://www.jst.mfeed.ad.jp/
インターネットマルチフィード時刻情報サービス for Public
http://www.eecis.udel.edu/~ntp/
(英語：Time SynchronizationServer -- Time Synchronization Server）
Microsoft社
NET TIME を使用して Time Source サーバーを特定する方法NET TIME /SET を使用してタイム ソース サーバーの検出方法
Windows Time Service の基本処理