ギガビットスクイージング：またはViPNet Client / Coordinatorの文書化されていない機能

みなさんこんにちは。 この投稿では、自発的な実験とサーバールームでの数時間が、WindowsバージョンのViPNet Custom 4.3のパフォーマンスに関して興味深い結果を得るのにどのように役立ったかについて説明しています。







もう興味がありますか？ 次に、猫の下を見てください。



1.はじめに



当初、このテストは単純に独自の内部実験でした。 しかし、私たちの意見では、結果は非常に興味深いものであったため、受け取ったデータを公開することにしました。



ViPNetカスタムソフトウェアとは何ですか？ つまり、これは、ロシアのFSBおよびFSTECの要件に従ってInfoTeKSが開発したファイアウォールと暗号化の複合体です。



ソリューションのテスト時には、さまざまな構成でのViPNetカスタムソフトウェアバージョンのパフォーマンス測定に関するデータはありませんでした。 ViPNetカスタムソフトウェアの実装の結果と、パフォーマンスがベンダーによって知られ文書化されているViPNet Coordinator HW1000 / HW2000のハードウェア実装と比較するのは興味深いことでした。



2.初期スタンドの説明



OJSC InfoTeKSのサイトinfotecs.ruのデータによると、HWプラットフォームの最も強力な構成には次の特徴があります。

種類	プラットフォーム	CPU	スループット
HW1000 Q2	AquaServer T40 S44	Intel Core i5-750	最大280 Mb / s
HW2000 Q3	AquaServer T50 D14	Intel Xeon E5-2620 v2	最大2.7 Gb / s

残念ながら、テスト条件に関する追加情報は提供されていません。



最初は、次の特性を持つ機器にアクセスできました。

1）IBMシステムx3550 M4 2 x E5-2960v2 10コア64 GB RAM;

2）Fu​​jitsu TX140 S1 E3-1230v2 4コア16GB RAM。



実験で富士通サーバーを使用することは疑問視されました...すぐに10GbEをストームしたいという欲求は、機器上のネットワークの不足によって防がれたので、出発点として残すことにしました。



IBMでは、ESX 6.0u1bプラットフォームに基づいた仮想10ギガビットスイッチを備えた2つの仮想サーバーを編成し、その後、2つの仮想マシンの全体的なパフォーマンスを評価しました。



スタンドの説明：



1.サーバーIBMシステムx3550 M4 2 x E5-2960v2 10コア64 GB RAM、ESXi 6.0u1。

仮想マシン（VM）ごとに、10コアの物理プロセッサが1つ割り当てられます。



VM1：Windows 2012 R2（VipNet Coordinator 4.3_（1.33043））：

•1つのCPU 10コア。

•8GB RAM。

VM2：Windows 8.1（ViPNetクライアント4.3_（1.33043））：

•1つのCPU 10コア。

•8GB RAM。



VMは10Gbps仮想スイッチに接続され、MTU 9000がインストールされます。



2. Fujitsu Server TX140 S1 E3-1230v2 4コア16Gb RAM、Windows 2012 R2、ViPNet Client 4.3_（1.33043）。



IBMおよび富士通の物理サーバーは、ギガビットネットワークによってMTU 9000に接続されています。ハイパースレッディングは両方のサーバーで無効になっています。 ロードソフトウェアとしてIperf3が使用されました。



スタンドのレイアウトを図1に示します。







図1-テストベンチの構成のスキーム



3.テストの最初の段階



残念ながら、この記事の準備はすべてのテストの後に開始されたため、このセクションでは、最終結果を除く結果のスクリーンショットは保存されませんでした。



3.1。 テスト番号1



最初に、1 Gb / sのネットワーク帯域幅を提供できるかどうかを評価します。 これを行うには、仮想コーディネーターVM1 Windows 2012 R2（ViPNet Coordinator 4.3）と物理サーバーFujitsu TX140 S1をロードします。



VM1側では、Iperf3はサーバーモードで実行されています。

サーバー側のFujitsu Iperf3がオプション付きで起動



Iperf.exe –cサーバーIP –P4 –t 100、



–P4パラメーターは、コアの数に等しいサーバー上のスレッドの数を示します。



テストは3回実施されました。 結果を表1に示します。



表1.テスト1の結果

ホスト	CPU負荷	負荷に達しました	チャンネル
VM1 Windows 2012 R2（ViPNet Coordinator 4.3）	<25％	972 Mbps	1Gbps
富士通TX140 S1	100％	972 Mbps	1Gbps

結果に基づいて、次の結論が出されます。

1）暗号化タスクのE3-1230v2プロセッサは、1Gb / sのネットワーク帯域幅を提供できます。

2）仮想コーディネーターの負荷が25％未満。

3）同様のプロセッサーを使用すると、ViPNet Coordinator HW1000の公式パフォーマンスはほぼ4倍を超えます。



取得したデータに基づいて、富士通TX140 S1サーバーが最大パフォーマンスに達していることが明らかです。 したがって、さらなるテストは仮想マシンでのみ実行されます。



3.2。 テスト番号2



それで、素晴らしいスピードが来ました。 仮想コーディネーターVM1 Windows 2012 R2（ViPNet Coordinator 4.3）およびVM2 Windows 8.1（ViPNet Client 4.3）をテストします。



VM1側では、Iperf3はサーバーモードで実行されています。

サーバーサイドVM2 Iperf3がオプション付きで起動



Iperf.exe –cサーバーIP –P10 –t 100、



–P10は、コアの数に等しいサーバー上のスレッドの数を示します。



テストは3回実施されました。 結果を表2に示します。



表2.テストNo. 2の結果

ホスト	CPU負荷	負荷に達しました	チャンネル
VM1 Windows 2012 R2（ViPNet Coordinator 4.3）	25〜30％	1.12 Gbps	10 gbps
VM2 Windows 8.1（ViPNetクライアント4.3）	25〜30％	1.12 Gbps	10 gbps

ご覧のとおり、結果は以前の結果と大差ありません。 次の変更を加えて、テストをさらに数回実行しました。

•iperfのサーバー部分がVM2に転送されます。

•Windows Server 2012 R2上のVM2のゲストOSをViPNet Coordinator 4.3に置き換えました。



テストしたすべての組み合わせで、結果は誤差範囲内で同じままでした。

ほとんどの場合、ViPNetソフトウェア自体に組み込みの制限があるという理解がありました。



いくつかのテストオプションの後、パラメーターを使用してIperf3が起動されたことが判明しました

Iperf.exe –cサーバーIP –P4 –t 100

帯域幅は、富士通サーバーで以前に達成された帯域幅とほぼ同じになりました。



同時に、4つのプロセッサコアが最も負荷が高くなりました-ちょうど25％の電力です。



得られた結果は、最終的に制限があることを確信しました。 結果は、問題の解決策を求めてメーカーに送信されます。



4.実験の継続



すぐに、メーカーからの応答が受信されました。

「プロセッサの数は、キー値HKLM \ System \ CurrentControlSet \ Control \ Infotecs \ Iplir、その値ThreadCountで制御できます。 値が-1であるか、設定されていない場合、スレッドの数はプロセッサの数に等しいが、4以下になります。値が設定されている場合、この値に等しいスレッドの数が選択されます。



まあ、推測は正しかった。 両方の仮想マシンでThreadCountパラメーターを10に設定して、パフォーマンスを最大にするスタンドを構成します。



4.1。 テスト番号3



必要なすべての変更を行った後、Iperfを再度起動します。



VM1側では、Iperf3はサーバーモードで実行されています。 サーバーサイドVM2 Iperf3がオプション付きで起動

Iperf.exe –cサーバーIP –P10 –t 100、



–P10は、コアの数に等しいサーバー上のスレッドの数を示します。



テストは3回実施されました。 結果を表3および図2-3に示します。



表3.テストNo. 3の結果

ホスト	CPU負荷	負荷に達しました	チャンネル
VM1 Windows 2012 R2（ViPNet Coordinator 4.3）	100％	2.47 Gbps	10 gbps
VM2 Windows 8.1（ViPNetクライアント4.3）	100％	2.47 Gbps	10 gbps

図2-VM1 Windows 2012 R2へのiPerf3の出力（ViPNet Coordinator 4.3）







図3-VM2 Windows 8.1（ViPNetクライアント4.3）へのiPerf3の出力



結果に基づいて、次の結論が出されます。

1）変更により、完全なプロセッサ使用率で最大の暗号化パフォーマンスを実現できました。

2）2つのXeon E5-2960v2を使用する場合の合計パフォーマンスは、5 Gbpsに等しいと見なすことができます。

3）2つのプロセッサの全体的なパフォーマンスを考慮すると、得られた暗号化パフォーマンスはViPNet Coordinator HW2000の公式結果を2倍超えています。



得られた結果は、あなたがさらに得ることができる関心を高めました。 幸いなことに、より強力な機器にアクセスできることがわかりました。



また、テスト中に、ViPNet ClientとViPNet Coordinatorの帯域幅に差がなかったことにも注意してください。



5.テストの第2段階



ViPNetのソフトウェア部分のパフォーマンスをさらに調査するために、次の特性を持つ2つの別個のブレードサーバーにアクセスしました。

•CPU 2 x E5-2690v2 10コア。

•ESXi 6.0u1。



各仮想マシンは、独自の「ブレード」に配置されます。



VM1：Windows 2012 R2（ViPNet Client 4.3_（1.33043））：

•2 CPU 20コア。

•32 GB RAM。



VM2：Windows 2012 R2（ViPNet Client 4.3_（1.33043））：

•2 CPU 20コア。

•32 GB RAM。



仮想マシン間のネットワーク接続は、MTU 9000との10 Gbpsサーバーブレード接続を介して行われます。両方のサーバーでハイパースレッディングが無効になっています。



負荷をシミュレートするために、iPerf3ソフトウェアに加えて、次の主要なパラメーターを持つNtttcpが使用されました。



1）受信側：



Iperf.exe –s;



送信側で：



Iperf.exe –cserver_ip –P20 –t100;



2）受信側：



NTttcp.exe -r -wu 5 -cd 5 -m 20、*、self_ip -l 64k -t 60 -sb 128k -rb 128k;



送信側で：



NTttcp.exe -s -wu 5 -cd 5 -m 20、*、server_ip -l 64k -t 60 -sb 128k -rb 128k



スタンドのレイアウトを図4に示します。







図4-テストベンチの構成のスキーム



5.1。 テスト番号4



まず、暗号化せずにネットワーク帯域幅をテストしましょう。 ViPNetソフトウェアがインストールされていません。



テストは3回実施されました。 結果を表4および図5-6に示します。



表4.テストNo. 4の結果

ホスト	CPU負荷	負荷に達しました	チャンネル
Tttcp	2.5％	8.5 gbps	10 gbps
Iperf	4％	9.3 gbps	10 gbps

図5-暗号化なしのNtttcpのテスト結果







図6-暗号化なしでIperfをテストした結果



結果に基づいて、次の結論が出されました。

1）10 Gbpsのネットワーク帯域幅が達成されました。

2）テストソフトウェアの結果に違いがあります。 さらに、信頼性のために、IperfとNtttcpの両方の結果が公開されます。



5.2。 テスト番号5



両方の仮想マシンでThreadCountを20に設定し、結果を測定します。



テストは3回実施されました。 結果を表5および図7〜8に示します。



表5-テストNo. 5の結果

ホスト	CPU負荷	負荷に達しました	チャンネル
Tttcp	74〜76％	3.24 Gbps	10 gbps
Iperf	68〜71％	3.36 gbps	10 gbps

図7-暗号化を使用したNtttcpのテスト結果







図8-暗号化を使用したIperfのテスト結果



結果に基づいて、次の結論が出されました。



1）単一のサーバーでは、ViPNet Coordinator HW2000の理論的なパフォーマンスを超えました。

2）5 Gbpsの理論的性能は達成されていません。

3）CPU負荷が100％に達していない。

4）テストソフトウェアの結果の違いは残りますが、現時点ではごくわずかです。



サーバー上のプロセッサが完全に使用されなかったという事実に基づいて、暗号化ストリームの同時数に対するViPNetドライバーの一部の制限に注意を払います。



制限を確認するために、暗号化操作中に1つのプロセッサコアを読み込むことを検討します。



テスト番号6



このテストでは、以前のテストの結果によると、パラメーターで大きなプロセッサ負荷が発生するため、Iperfのみを使用します。



Iperf.exe –cIP_server –P1 –t100。



レジストリを介して各サーバーで、暗号化操作中に1つのコアを使用するようにViPNetを制限します。



テストは3回実施されました。 結果を図9-10に示します。







図9-暗号化操作中の1つのコアの使用率







図10-シングルコアをロードするときに暗号化を使用してIperfをテストした結果



結果に基づいて、次の結論が出されました。



1）シングルコアが100％ロードされました。

2）1つのコアの負荷に基づいて、20のコアで5.25 Gbpsの理論的なパフォーマンスが得られます。

3）シングルコアのロードに基づいて、ViPNetソフトウェアには14コアの制限があります。



コアの制限を確認するために、プロセッサに含まれる14個のコアで別のテストを実施します。



テスト番号7



14コアの暗号化を使用したテスト。



このテストでは、パラメーター付きのIperfのみを使用します



Iperf.exe –cIP_server –P12 –t100。



レジストリを介して各サーバーで、暗号化操作中に使用するコアが14を超えないようにViPNetを制限します。







図11-暗号化操作中の14コアの廃棄







図12-14コアをロードするときに暗号化を使用してIperfをテストした結果



結果によると、結論が下されます：



1）14コアすべてがロードされました。

2）パフォーマンスは20コアのオプションに似ています。

3）マルチスレッド暗号化操作には14コアの制限があります。



テスト結果は、問題の解決策のリクエストとともにメーカーに送信されました。



6.結論



しばらくして、製造元からの応答が受信されました。



「Windowsコーディネーターでの4つ以上のコアの使用は文書化されていない機能であり、その適切な動作は検証も保証もされていません。」



これでテストを終了できると思います。



テスト結果でソフトウェアバージョンがかなり先行しているのはなぜですか？



ほとんどの場合、いくつかの理由があります。

1）古いテスト結果。 非公式データによると、新しいファームウェアでは、HWのパフォーマンスが大幅に向上しています。

2）文書化されていないテスト条件。

3）最大の結果を得るために、文書化されていない機会が使用されたことを忘れないでください。



まだ質問がありますか？ コメントで彼らに聞いてください。



アンドレイ・クルタサノフ、ソフトライン