NTP(時刻同期)を利用する時の「サーバー・クライアント間通信」には以下の通信方法が存在します。
- ユニキャスト
- ブロードキャスト
- マルチキャスト
- メニーキャスト
今回の記事では、「どの方式をどういう時に使えばいいのか」や「メリデメ」を考えてみます。
- RedHat(CentOS)を想定しています。(ntpd想定でchrony.confではない)
- プライベートな環境(インターネット越しのNTP同期は考慮外)で考えます
各方式のまとめ
まずはそれぞれについて簡単に内容を把握します。
通信方式 | クライアント側の設定(ntp.conf) | サーバー側の設定(ntp.conf) | 通信方向 | コメント |
---|---|---|---|---|
ユニキャスト | server [address] |
なし | クライアントからサーバーに問い合わせる | |
ブロードキャスト | broadcastclient |
投げ先のセグメントを指定broadcast [address] |
サーバーからクライアントにブロードキャストで投げつける | デフォルトで認証を必要とする |
マルチキャスト | multicastclient [address] |
投げ先のセグメントを指定broadcast [address] |
クライアントからサーバーに問い合わせる | デフォルトで認証を必要とする |
メニーキャスト | manycastclient [address] |
投げ先のセグメントを指定manycastserver [address] |
なし |
ユニキャストについて
一番わかりやすいですね。
server [address1] server [address2]
などと設定することで対象のNTPサーバーに同期しに行きます。各サーバー全てに同じ設定をしなければならないことがボトルネックでしょうか。
あとはNTPサーバーが入れ替わった時にホスト名の解決をDNSでしていないなら、全て直す必要がありますね。
ブロードキャストについて
ブロードキャストはその名の通り、サーバーからNTPのパケットをブロードキャストします。
クライアント側に「対象のセグメントを監視しておきますよ(NTPのパケットが来るかどうか見るよ)」という意味のbroadcastclient
を入れておけば勝手に同期されますので特に難しいことを考える必要はありません。
NTPサーバーがリプレースされた場合も設定が不要です。(ホスト名をDNS解決している場合はDNSレコードの修正をすればいいのでこのメリットはありません)
一方でブロードキャスト通信はルーターを超えることができず破棄されますのでNTPの同期先は同一セグメント(IPアドレス帯)となります。大規模で複雑なネットワーク構成を組んでいる環境には合わないですね。
ブロードキャストとマルチキャストにおける認証について
インターネット上のNTPサーバーを使う場合においては認証が必要だと思いますが、プライベートな環境であれば怪しいNTPサーバーがいきなり登場して汚染される可能性は低い(というかそこまでできるならもっと他のことをやるだろう・・・)ということで認証は不要と考えます。
デフォルトで認証は設定されていますが、ntp.conf ファイル内の disable auth ディレクティブを使って認証を無効にすることもできます。
別 参考:16.6. NTP の認証オプション
マルチキャストについて
特定のマルチキャストアドレスをサーバーとクライアントに設定することで、マルチキャスト通信を行うモードです。ブロードキャストと同じく、サーバーが特定のセグメントに投げつけてクライアント側がそれを監視しておく形になります。
IPv4 Class D アドレスか IPv6 アドレスになります。IANA は IPv4 マルチキャストアドレス 224.0.1.1 と IPv6 アドレス FF05::101 (サイトローカル) を NTP に割り当てています。『RFC 2365 Administratively Scoped IP Multicast』 の説明にあるように、管理者が範囲指定した IPv4 マルチキャストアドレスも使用可能です。
引用元:16.17. NTP の設定
ブロードキャストと異なるのは、クライアントとサーバー側にマルチキャスト用のアドレスを設定する必要があり、ルーターにもマルチキャスト対応が求められます。
しかし、下記の記事でも記載されているようにマルチキャストにはサーバー→ルーター→クライアント間通信のうち、サーバー→ルーター間の通信量を軽減することもできますので、大量にネットワーク越しのNTPをさばくには向いていると思われます。
マルチキャストを利用すれば,あて先すべてに同じデータを送る作業は必要なくなる。ルーターにパケットを一つ送れば,あとはルーターがパケット内のデータを必要な数だけコピーして,それぞれに転送してくれるからだ。送信元からあて先までの経路上に流れるパケットは重複しないので,ユニキャストに比べて効率的に通信できる。
ただ、実際Googleなどが公開しているNTPサーバーも、私たちのパソコン側でIPアドレスを直指定したユニキャスト通信になっていますし、いまだにマルチキャストをNTPで使っているところをお目にかかったことがないのでレアな設定ですね。
メニーキャストについて
RedHatの説明を読むと下記のように記載されています
manycastclient address
ここでの address は IP マルチキャストアドレスで、ここからパケットが受信されます。クライアントはこのアドレスにリクエストを送信し、応答から最善のサーバーを選んで他を無視します。その後は、NTP 通信は発見された NTP サーバーが ntp.conf リストされているかのようにユニキャスト関連付けを使用します。
メニーキャストは以下の順番でNTPを実現しています
- クライアントがサーバーのマルチキャストアドレスに対してNTP同期リクエストを送る
- マルチキャストアドレスを保有するサーバーがレスポンスを返し、何らかのロジックでクライアント側が最適なサーバーを選択する
- 以後は、2で選択したサーバーに対してユニキャスト通信を行う
動的なNTP構成を実現でき、ルーターも超えられますがいかんせん世の中で使っている人の数(ググっても情報が出てこない)からしてマイナーそうでトラブル時に苦労しそうです。
マルチキャストの設定もする必要があるため面倒ですが、享受できるメリットがそこまで大きくないように感じます。
まとめ
NTPの構成は基本的にそうそう変わるものでもない(と思っている)ので、個人的にはユニキャストでいいかなあと思います。
通信方式 | おすすめ | メリット | デメリット |
---|---|---|---|
ユニキャスト | ◎ | 設定が簡単 | NTPサーバー変更時やNTPサーバー設定追加時に柔軟に対応できない |
ブロードキャスト | ○ | 設定が簡単、リプレースも簡単 | 別セグメントのNTPサーバーにアクセスできない |
マルチキャスト | △ | NTPサーバー→ルーターのNW帯域軽減、NTPサーバーの追加が簡単 | マルチキャスト設定が必要 |
メニーキャスト | △ | 複数のNTPサーバーを簡単に指定できる、NTPサーバーの追加が簡単 | マルチキャスト設定が必要 |