お世話になっております、よろしくお願いします。
フレッツ光のv6オプションを利用してNGN網内にSoftetherVPNのトンネルを張り、
2つの拠点を接続をしております。
2つの拠点間スループットはiperf計測で100~150Mbpsと、まずまずの速度が
出ているのですが、SoftetherVPN Server/Bridgeに使用しているCentOS間で
直接IPv6でのiperfを計測するとおよそ400Mbps出ているので、これに近い
値まで高速化できないかと画策しております。以下はざっくりとした構成です。
特に断りのない限り、2拠点とも共通のスペックとします。
・回線はNTT東日本のフレッツ光ネクスト
・フレッツサービス情報サイト計測の速度はおおむね400~600Mbps
・ローカルネットワークおよびNGNのパケロス率はほぼ0%
・SoftetherVPN Server/Bridgeに使用しているOSはCentOS7(Linux KVM仮想環境上)
・SoftetherVPN Server/BridgeのNICは物理IFモデルからTAPインターフェースへ変更済み、その際約2割速度向上
・使用するTCPセッション数は最大の32へ変更
・TAP接続先ブリッジIFのMTUサイズをデフォルト1500から1454へ変更したものの、若干速度低下
・SoftetherVPN Server/BridgeのCPU使用率にはまだ余裕あり(ホストOSで見た使用率はピーク18%程度)
・SoftetherVPN Server/Bridgeのメモリスワップ発生なし
さらなる高速化の方法があれば是非お教えください。
以上、よろしくお願いします。
拠点間接続のさらなる高速化について
-
- Site Admin
- Posts: 2266
- Joined: Sat Mar 09, 2013 5:37 am
Re: 拠点間接続のさらなる高速化について
TAPモードのローカルブリッジはドライバの制約でカーネルに複数のパケットを同時に渡せないため、性能が頭打ちになる傾向があります。
通常は物理デバイスにローカルブリッジを設定したほうがスループットは高くなります。
TAP に変更してスループットが上昇したということなので、ローカルブリッジ先のドライバ側に何らかの問題がある可能性が考えられます。
NICのオフロード機能と衝突している可能性が考えられるので、オフロード機能は可能な限りOFFにしてみてください。
また、TCPセッション数は多くし過ぎるとパケットの順序が入れ替わる確率が上がるため、UDP性能は高くなる場合もありますが、TCPでのスループットは落ちてしまう場合があるようです。
(それ以前にUDPで直接通信が可能で、UDP高速化モードが有効になっている場合は、TCPセッション数は速度に影響しません。)
通常は物理デバイスにローカルブリッジを設定したほうがスループットは高くなります。
TAP に変更してスループットが上昇したということなので、ローカルブリッジ先のドライバ側に何らかの問題がある可能性が考えられます。
NICのオフロード機能と衝突している可能性が考えられるので、オフロード機能は可能な限りOFFにしてみてください。
また、TCPセッション数は多くし過ぎるとパケットの順序が入れ替わる確率が上がるため、UDP性能は高くなる場合もありますが、TCPでのスループットは落ちてしまう場合があるようです。
(それ以前にUDPで直接通信が可能で、UDP高速化モードが有効になっている場合は、TCPセッション数は速度に影響しません。)
-
- Posts: 19
- Joined: Sat Oct 04, 2014 1:06 pm
Re: 拠点間接続のさらなる高速化について
お世話になっております、ご回答ありがとうございます。
アドバイスいただいた通り"ホストOS"で使用している各拠点の
CentOS7オフロード機能を切ってみました。
オフロード機能の知識がほとんど無かったため、とりあえず
以下のページを参考に4つのオフロード機能を無効化しました。
http://qiita.com/semind/items/9b48c6655ced95a42b03
>rx-checksumming
>tx-checksumming
>tcp-segmentation-offload
>generic-receive-offload
ただ残念ながらスループットは同程度か、やや低下するという結果でした。
念のため物理デバイスブリッジとTAPモードブリッジ両方をオフロード無効化した
状態で比較しましたが、やはり今回もTAPモードのほうがやや早いという結果でした。
その他追記事項です。
・Bridge側で確認すると、「UDP高速化機能をサポート」「UDP高速化機能を使用中」はいづれも"はい"になっています
・Linux KVMで使用しているNICのドライバモデルはIntel e1000タイプです(virtioはバグの為今回の構成で使用できません)
その他ご意見がございましたらよろしくお願いします。
以上です。
アドバイスいただいた通り"ホストOS"で使用している各拠点の
CentOS7オフロード機能を切ってみました。
オフロード機能の知識がほとんど無かったため、とりあえず
以下のページを参考に4つのオフロード機能を無効化しました。
http://qiita.com/semind/items/9b48c6655ced95a42b03
>rx-checksumming
>tx-checksumming
>tcp-segmentation-offload
>generic-receive-offload
ただ残念ながらスループットは同程度か、やや低下するという結果でした。
念のため物理デバイスブリッジとTAPモードブリッジ両方をオフロード無効化した
状態で比較しましたが、やはり今回もTAPモードのほうがやや早いという結果でした。
その他追記事項です。
・Bridge側で確認すると、「UDP高速化機能をサポート」「UDP高速化機能を使用中」はいづれも"はい"になっています
・Linux KVMで使用しているNICのドライバモデルはIntel e1000タイプです(virtioはバグの為今回の構成で使用できません)
その他ご意見がございましたらよろしくお願いします。
以上です。
-
- Site Admin
- Posts: 2266
- Joined: Sat Mar 09, 2013 5:37 am
Re: 拠点間接続のさらなる高速化について
KVMは使用したことがないので分からないのですが、KVMでは仮想環境からハードウェアへのIOは
直接行えず、仮想デバイスのエミュレーションを介してアクセスする仕組みのようです。
VPN通信とローカルブリッジの通信を行う分、直接の通信よりもIOの粒度は小さくなり、通信の
頻度も量も増大するため、この部分がボトルネックになっているということはないでしょうか。
直接行えず、仮想デバイスのエミュレーションを介してアクセスする仕組みのようです。
VPN通信とローカルブリッジの通信を行う分、直接の通信よりもIOの粒度は小さくなり、通信の
頻度も量も増大するため、この部分がボトルネックになっているということはないでしょうか。
-
- Posts: 19
- Joined: Sat Oct 04, 2014 1:06 pm
Re: 拠点間接続のさらなる高速化について
アドバイスありがとうございます。
試しにVMではなくそれらが稼働していた物理ホスト側にそれぞれSoftetherVPNを
インストールしてみました。すると今度は最高で220Mbps近くまでスループットが向上しました。
ただし稼働させているOSがCentOS6-CentOS7ということと、物理機器の数が足りないことから
CentOS6側の拠点はその上で稼働するVMでiperfの計測をしています。
仮想NICを経由しての測定である為、実際どこまでスループットが引き上げられたのか
正確には未知数です。
何れにせよ仮想NICを介してのトンネリングはそれなりのペナルティを伴うということが理解できました。
ありがとうございます。
ただまだ少し気になっていることがあります。以下のページによると、(ハイパフォーマンス物理サーバかつ
10GbEとはいえ)SoftetherVPNは実測で980Mbpsを記録したと謳われています。
https://ja.softether.org/1-features/1._ ... F.E7.8F.BE
諸条件が異なるので一概に比較はできませんが、今回私が検証した結果も鑑みても
プロトコルそのものはまだ伸びしろがあることから、SoftetherVPNはWindows Serverに
対して最適化されているということでしょうか?
またSoftetherVPNは細かなパラメーターチューニングフリーを謳っているところがありますが、
インストール先のOSやNICを含めたパフォーマンスを出すための設定の勘所、あるいは
仮想環境で実行する場合のコンパチビリティー情報(推奨されるベアメタルや仮想NICモデルなど)の
情報は開示されていないのでしょうか?
以上、よろしくお願いします。
試しにVMではなくそれらが稼働していた物理ホスト側にそれぞれSoftetherVPNを
インストールしてみました。すると今度は最高で220Mbps近くまでスループットが向上しました。
ただし稼働させているOSがCentOS6-CentOS7ということと、物理機器の数が足りないことから
CentOS6側の拠点はその上で稼働するVMでiperfの計測をしています。
仮想NICを経由しての測定である為、実際どこまでスループットが引き上げられたのか
正確には未知数です。
何れにせよ仮想NICを介してのトンネリングはそれなりのペナルティを伴うということが理解できました。
ありがとうございます。
ただまだ少し気になっていることがあります。以下のページによると、(ハイパフォーマンス物理サーバかつ
10GbEとはいえ)SoftetherVPNは実測で980Mbpsを記録したと謳われています。
https://ja.softether.org/1-features/1._ ... F.E7.8F.BE
諸条件が異なるので一概に比較はできませんが、今回私が検証した結果も鑑みても
プロトコルそのものはまだ伸びしろがあることから、SoftetherVPNはWindows Serverに
対して最適化されているということでしょうか?
またSoftetherVPNは細かなパラメーターチューニングフリーを謳っているところがありますが、
インストール先のOSやNICを含めたパフォーマンスを出すための設定の勘所、あるいは
仮想環境で実行する場合のコンパチビリティー情報(推奨されるベアメタルや仮想NICモデルなど)の
情報は開示されていないのでしょうか?
以上、よろしくお願いします。
-
- Posts: 19
- Joined: Sat Oct 04, 2014 1:06 pm
Re: 拠点間接続のさらなる高速化について
追伸
一つ前の構成(物理ホスト同士の接続)において、ブリッジ先インターフェースを
物理からTAPインターフェースに変更したところ、450Mbpsを記録しました。
ほぼ上限値です。理由はわかりませんが、結果としては満足いくものが得られました。
一つ前の構成(物理ホスト同士の接続)において、ブリッジ先インターフェースを
物理からTAPインターフェースに変更したところ、450Mbpsを記録しました。
ほぼ上限値です。理由はわかりませんが、結果としては満足いくものが得られました。
-
- Site Admin
- Posts: 2266
- Joined: Sat Mar 09, 2013 5:37 am
Re: 拠点間接続のさらなる高速化について
主に Windows をターゲットにチューニングを行っているため、Windows の方が
高い性能が出やすい傾向にはあると思われます。
また、Linux では NIC から IP スタックを切り離せないため、ローカルブリッジ時に
受信するパケットに OS で不要な IP 処理が行われてしまうという問題もあります。
また、パフォーマンス実験では、サーバーとクライアントは直結して設置されていたため
遅延が極めて小さかったことがスループットに影響している可能性が高いと思われます。
高い性能が出やすい傾向にはあると思われます。
また、Linux では NIC から IP スタックを切り離せないため、ローカルブリッジ時に
受信するパケットに OS で不要な IP 処理が行われてしまうという問題もあります。
また、パフォーマンス実験では、サーバーとクライアントは直結して設置されていたため
遅延が極めて小さかったことがスループットに影響している可能性が高いと思われます。
-
- Posts: 19
- Joined: Sat Oct 04, 2014 1:06 pm
Re: 拠点間接続のさらなる高速化について
承知しました。
今後は物理機器を前提に構築することを念頭に入れておきます。
上記の仮想環境に伴う留意事項も公式ページの注意書きに
追加いただけると幸いです。
回答いただきありがとうございました。
今後は物理機器を前提に構築することを念頭に入れておきます。
上記の仮想環境に伴う留意事項も公式ページの注意書きに
追加いただけると幸いです。
回答いただきありがとうございました。