OpenVPN はマルチキャストを購読者ではなく全クライアントに配信する

「マルチキャストに対応」はプロトコルの問いに答えるだけで、容量の問いには触れていません。運用上重要なのは、サーバーが ひとつのグループパケットに対して何部のコピーを送るのか、そしてどのトンネルがそれを運ぶのかです。購読したアプリがストリームを受け取っても、配信がどこかで動くことしか証明できません。関心のないクライアントが帯域を免れたことは証明できません。

ひとつの機能表明に含まれる三つの問い

グループ参加は、受信者がグループに入ったかを問います。トンネル配信は、パケットがそもそもトンネルを通過したかを問います。複製ポリシーは、サーバーが何部のコピーを誰に作ったかを問います。ベンダーの説明は前者については正しく、後者については沈黙していてもよく、コストはそこにあります。

回線のサイズを見積もるときは、これらを分けて扱ってください。サーバー側の送信予算を決めるのは 三番目の問いだけです。

ユーザー空間サーバーはグループパケットをどう扱うか

従来のユーザー空間サーバー OpenVPN 2.6 では、到着したブロードキャストまたはマルチキャストのパケットは TUN/TAP の入力経路で分類され、グループごとの検索ではなくブロードキャストのファンアウト処理に渡されます。その処理はクライアントインスタンスをたどり、送信者と停止中のインスタンスを飛ばし、VLAN が設定されている場所ではその検査を適用し、残るクライアントごとにコピーをキューに入れます。そのループのどの段階も参加者テーブルを参照しません。これがブロードキャスト方式の複製であり、仕組みはこれだけです。

これはそのコード経路の性質として扱い、普遍的な法則とは考えないでください。高速化されたデータ経路、他の実装、異なるバージョンでは挙動が異なることがあり、いずれも TAP を要件や修復にするものではありません。

何かを測定する前にコピーの予算を立てる

ペイロードレートを取り、対象クライアント数を掛けます。一秒あたり一メガビットを二十クライアントへ送るストリームは、カプセル化、再送、クライアントごとのオーバーヘッドの前に、サーバーを出る 一秒あたり二十メガビットのペイロードを生みます。その算術は予算であり、あなたの配備の測定値ではありません。

ip -s link show tun0

既知の送信者をひとつ動かした状態で、一定区間の前後で送信バイトのカウンターを読みます。区間で割り、ペイロードレートにクライアント数を掛けた値と比較します。単一ストリームのレートに近ければ複製は範囲限定であり、掛けた値に近ければ全クライアントがコピーを受け取っています。

カウンターには自分自身のトンネル通信も含まれるので、試験区間は短くし、ホストはそれ以外静かにしてください。精度より桁の大きさが重要で、一部と二十部を区別するにはそれで十分です。

範囲の問いを決着させる二クライアントの試験

ストリームを受け取るべきクライアントと、受け取るべきでない 二台目を接続します。送信者を起動し、同じ区間で 二台目のトンネルカウンターを見ます。二台目に増加があれば、機能一覧が何と言っていても、広い複製の直接の証拠です。

キャプチャはグループアドレスで絞り、無関係な通信を読まないようにし、トンネルインターフェースに限定します。混雑したホストで物理インターフェースを取得すると、誰にも解釈できないファイルができ、収集するつもりのなかった利用者データが残る可能性があります。

次に役割を入れ替えます。結果がグループではなく受信者に従うなら、参加を意識した何かを見ており、以前の前提はあなたに有利に外れていたことになります。

制限を取り除くのではなく範囲を限定した設計を選ぶ

ファンアウトが広すぎるときの修正は、持っている統制をすべて削除することではなく、対応済みの範囲限定の配信構成です。選択肢には、配信点を受信者の近くへ移す、グループとともに送信元の識別子を運ぶ送信元固有の購読モデルを使う、関心のない拠点が同じ配信境界に置かれないようストリームを分割する、などがあります。

送信元とグループの識別子は、宛先がマルチキャストであるというだけの事実と切り離してください。グループは認識しても送信元を認識しない受信者は、特定のチャネルを求めた購読者とは別の購読者です。両者を混ぜると、後日の容量計画が当て推量になります。

送信元固有のマルチキャストチャネルモデルがその区別の参照です。どの設計を選んでも、対象ピアの集合、複製の責任者、次回に読むカウンターを書き留めておけば、その記録が帯域の驚きを既知のコストに変えます。