- ライター：新林 辰則
- 2007年にネットワンシステムズに入社
ロードバランサー製品の製品技術担当を経て、現在はSDN・仮想化の製品・技術領域を担当し製品や技術の評価検証、お客様への提案の技術支援等を行っている。
最近はプログラマブルネットワークにも注目し、情報収集活動、セミナーでの発表などを実施。
目次
ネットワーク製品においてパフォーマンスは重要な要素の一つであり、多くご質問をいただくところでもあります。
今回はVMware社のVMware NSX Advanced Load Balancer（以下 NSX ALB）について、弊社ラボにてトラフィックジェネレータを使用し計測を実施いたしましたので、その結果と計測を実施し得られた知見についてご紹介させていただければと思います。
NSX ALBはソフトウェアベースで、vSphere仮想基盤上やパブリッククラウド等、幅広いインフラストラクチャ上にデプロイ可能です。
また、高度なロードバランサーとしての機能を持ちつつ、コントロールプレーンからの集中管理とトラフィックの可視化/分析機能を提供する、次世代型のロードバランサーとなります。
NSX ALBについては以下関連記事にも記載させていただいておりますので、是非ご覧ください。
新しいロードバランサーのカタチ - NSX Advanced Load Balancer 概要 -
メーカ公開のデータシートと今回の計測結果の比較
計測結果の前に、今回の構成図を下記に図示します。
vCenter ServerやNSX ALBコントローラといった管理系のコンポーネントはESXi1上にデプロイし、Service Engineは別のESXi2上にデプロイすることで、Service Engine以外の仮想マシンが存在しない環境で測定を行った結果となっています。
既存のパフォーマンスデータとしては、メーカからも公開されているデータシート情報があります。
NSX ALBの場合はService Engineと呼ばれるデータプレーンが仮想マシンとしてデプロイされ、実際のトラフィックの転送をコントローラからの設定に従って処理するため、その仮想マシンに割り当てるvCPU数がパフォーマンスに大きく関わってきます。
また、複数のService Engineで分担して一つのVIP宛のトラフィックをActive/Activeで捌くことも可能であるため、vCPUの使い方として1個のService EngineのvCPU数を増やす（スケールアップ）使い方と、1vCPUのService Engineを複数横に並べる（スケールアウト）使い方の2種類があります。
その点も踏まえ、Service Engineのデプロイ方式を含めて既存データシートの情報と今回の計測結果としては下記になります。
※メーカデータシートで使用のCPU：Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
※今回計測で使用したCPU：Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz
※SE＝Service Engineの略になります。
今回用意できたサーバのCPUモデルによる差がでている結果ではあるかと思いますが、メーカデータシート以外のCPUモデルによる一つの指標として、参考情報が計測できたのではないかと考えています。
計測の実施によって得られた知見
- スケールアップ vs スケールアウト
今回の計測ではスケールアップ型のvCPUの使い方と、スケールアウト型の使い方の両方を計測してみました。
それぞれのグラフの左側3本の棒グラフがスケールアップ型、右の2本の棒グラフがスケールアウト型での計測となります。
L7トランザクション、SSLトランザクション共にスケールアウト型でService Engineをデプロイしたパターンの方が若干パフォーマンスが出やすい結果となりました。
ただ、スケールアウトしてService Engineをどんどん増やしていくと、クライアントからのコネクションを他の各Service Engineに割り当てるディスパッチャーService Engineの負荷が高まることが予想されるため、L2でスケールアウトを行うL2 Scale Outと呼ばれるスケールアウト方式では、Virtual Service毎に4台のService Engineまでに留めておくのが良いという推奨事項※が案内されております。
※注1 L2 Scale OutではVirtual Serviceごとに4のService Engineが推奨ですが、Service Engine Groupとしては最大1000まで拡張が可能です。
※注2 BGP を利用した L3 Scale Out構成では最大64 Service Engineまで拡張対応が可能です。
そのため、L2 Scale Out方式におけるパフォーマンス増強の方針としては4つのService Engineまではスケールアウト型で対応し、それ以上のパフォーマンス増強が必要な場合は各Service Engineをスケールアップしていくという方針が良いかと考えます。
- VIPに可視化/分析用ログ取得の設定を実施した場合のService Engine CPUインパクト
NSX ALBの特徴のひとつとして、遅延やアクセスログ、L7トランザクション毎の詳細な状況等を可視化/分析できる機能が充実しており、トラブルシューティングやVIP毎の負荷状況からService Engine（vCPU）の割り当て状況を見直すなど様々な使い方が可能となっております。
VIP毎に秒間どの程度のログを取得するのかを設定することができ、今回はその秒間ログ取得数を増加させた場合にService EngineのCPUへパフォーマンスインパクトがあるのかどうかを見てみました。
結果としては上記の通り、1つのVIPに対して10000Log/Secのログ取得を有効にした場合でもService EngineへのCPU負荷はほぼ見られない形になりました。今回は1つのVIPでの計測結果であるため、複数のVIPによる負荷やコントローラ側の負荷は計測できておりませんが、そもそものところでログ取得等本来のパケットフォワードとは別の機能を有効化するというのはデータプレーン側への負荷が高まらないか不安要素になる部分ではありましたので、良い指標ができたのではないかと思います。
まとめ
今回の記事では、弊社でVMware NSX Advanced Load Balancerのパフォーマンスを計測した結果を共有しました。このような性能検証以外にも弊社ではNSX ALBに関する様々な検証を実施しており、お客様への導入の際のノウハウとして活かしています。
VMware NSX-T Data Center（以下 NSX-T）においても昨年12月にリリースされたVersion 3.2.0より、NSX-T ManagerからNSX ALBを展開することが可能となっています。また、NSX-Tの今後の新規展開においては、NSX-Tネイティブのロードバランサーではなく、NSX ALBを利用していくことが推奨されており、今回ご紹介しましたNSX ALBの重要性が一層高まることが予想されます。
次回はNSX-TからNSX ALBを展開し利用するまでのBlog記事をご紹介予定ですので、是非ご覧いただければと思います。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
