OpenVPN に必要なコア数はいくつか？経路によって変わる

同じプロセッサ数を積む二台のサーバーでも、実現できるスループットは大きく異なる。重要なのは、有効なデータ経路が実際に何コア使えるかという数であり、クライアント一つのパケットを処理する単一のユーザー空間デーモンはコア一つに縛られる一方、カーネルへオフロードした経路はその作業を分散できる。どちらの説明も、与えられたマシンがあなたのトラフィックで何をするかまでは教えてくれないため、測定はコア数を数えるより先に来る。

以下の比較は、パケットをどこで処理するかという話であり、どの製品が抽象的に速いかという話ではない。これは別の問いであり、答えも別だ。

ユーザー空間の経路ではフローごとにコア一つ

従来の Community OpenVPNインスタンスでは、データチャネルはユーザー空間で処理され、忙しい接続が一つの CPU を占有してもマシン全体の使用率は目立たない。だからこそ、すでに一つのフローで飽和しているホストにコアを足しても何も変わらない。スケジューラにはその作業を分割する手段がないからだ。クライアントごとにプロセスを分ける構造は、総コア数に関係なく一つのクライアントの転送をコア一つの能力に縛るので、試験中は合計値ではなくコアごとの使用率を読むこと。

一台のホストで複数のサーバーインスタンスを動かすと、別々のクライアントがプロセスに振り分けられる。ただし既存の接続が並列化されるわけではなく、プール、リスナー、ルーティングの判断も別々に必要になる。

もう一つの経路: カーネル内のパケット

データチャネルのオフロードは、対応するパケット処理と暗号処理をカーネルへ移し、そこで複数のコアを使えるようにする。これにより容量の問いはコア一つからマシン全体へ変わるが、実装が対応する構成、すなわち互換性のあるカーネルモジュール、適格なデータ暗号、オフロードが除外する機能を含まない構成に限られる。モジュールを導入したことは、それを使っていることと同じではないため、接続自身のログや状態出力で有効なモードを確認すること。バージョンの表示は何が利用可能かを示すだけで、何が実際に動いているかは示さない。

オフロードは認証や制御チャネルを取り除くものではなく、あらゆる配備をマルチコアにするものでもない。互換性のあるデータ経路の局所的な高速化であり、要件はプラットフォームとバージョンによって異なる。

比較が実際に決めること

本当の選択は、フローごとの上限を受け入れるか、クライアントをインスタンスへ分散するか、対応済みのオフロード構成へ移るかである。どれも別の問題に対処するもので、間違ったものを選べば数字を動かさないまま費用だけがかかる。重要な試験は、サービスの使われ方に沿った形のものである。

一つのクライアントで一つの転送、一つのクライアントで複数のフロー、そして複数のクライアントを同時に動かす場合という三つの形を測る。三つ目の合計が高くても単一のダウンロードがそこへ届く証明にはならず、単一の転送が遅いからといってサーバーの総容量が尽きた証明にもならない。結果は別の問いに答えるもので、どちらも取っておく価値がある。

一つのクライアント内部の並行性が効くかどうかを教えるのは真ん中の形だけであり、それは通常サーバーではなくトランスポートと経路の性質だ。単一のアプリケーションが見る上限を教えるのは最初の形だけである。比較に意味を持たせるため、実行の間で作業負荷を同じに保つこと。

数字に意味を持たせるための測定

サーバーとクライアントのバージョン、有効なデータ経路、交渉されたデータ暗号、転送方向、パケットサイズ、フロー数、時間を記録する。コアごとの動きと両端のパケットおよびキューのドロップを見るのは、クライアント自身のインターフェース、プロバイダーのネットワーク、宛先サービスが先に限界になることがあるからだ。暗号、圧縮、MTU、オフロードを同時に変えた実行ではどれが効いたのか分からないため、一度に一つの変数だけを変えること。誰も動かさない実験室の設定はほとんど何も証明しないため、試験中は実際に配備するつもりのアクセス方針を保つこと。

そのうえで、制御チャネル、再ネゴシエーション、そしてホスト上で動くその他すべてのために余裕を残しておく。

他の誰かのハードウェアから外挿した速度ではなく、想定した並行性のもとでその構成が実際に維持した数値を報告すること。試験条件を添えた数字は役に立つが、条件のない約束は後で引用されて返ってくる単なる推測だ。