NSX Advanced Load Balancer は、NSX Advanced Load Balancer SE の最小および推奨リソース要件を公開します。このセクションでは、サイジングの詳細について説明します。正確な要件に合わせて調整された推奨事項については、NSX Advanced Load Balancerセールス エンジニアにお問い合わせください。

SE は、1 つの vCPU コアと 2 GB の RAM で構成でき、最大 64 個の vCPU コア、256 GB の RAM を使用できます。

注:

GeoDB を使用している場合は、ServiceEngine に少なくとも 4 GB のメモリを使用することを推奨します。

書き込みアクセス モードでは、SE グループのプロパティ内で新しく作成された SE の SE リソースを構成できます。

読み取りモードまたは Orchestrator なしモードの SE の場合、SE リソースは展開時に SE 仮想マシンに手動で割り当てられます。

NSX Advanced Load Balancer SE のパフォーマンスは、ハードウェア、SE のスケーリング、使用される暗号と証明書など、いくつかの要因によって決まります。パフォーマンスは、次のプライマリ ベンチマーク メトリックに分類できます。

  • 1 秒あたりの接続、要求、SSL トランザクション (CPS/RPS/TPS):主に使用可能な CPU によって制限されます。

  • 一括スループット:CPU、PPS、および環境固有の制限に依存します。

  • 同時接続数:SE メモリに依存します。

このセクションでは、想定される実際のパフォーマンスおよび SE 内部のコンピューティングとメモリ使用量について説明します。

CPU

NSX Advanced Load Balancerは、AMD および Intel のプロセッサを含む x86 ベースのプロセッサをサポートします。AES-NI と同様の機能強化を備えた AMD および Intel のプロセッサを活用することで、連続する各世代のプロセッサで NSX Advanced Load Balancer のパフォーマンスが着実に向上します。

CPU は、SSL ハンドシェイク (TPS)、スループット、圧縮、WAF 検査の主要な要素です。



CPU 使用率の制限または環境の制限がしきい値に達していない場合、CPU によってパフォーマンスが直線的に向上します。CPU は 1 秒あたりのトランザクション数と一括スループットの両方に対する第一の制約です。

CPU は、1 秒あたりのトランザクション数と一括スループットの両方に対する第一の制約であるため、サービス エンジンに割り当てられた CPU コア数を増やすと、ほぼ直線的に SSL パフォーマンスが向上します。1 つの SE で最大 36 個の vCPU コアをスケール アップできます。SE 内では、1 つ以上の CPU コアにディスパッチャー ロールが付与されます。NIC とインターフェイスし、システム内の他のコア間でネットワーク フローを分散し、トラフィックを他の CPU コアに効果的にロード バランシングします。各コアは、仮想サービス構成によって決定される TCP、SSL、およびその他の処理を終了します。図に示す vCPU 0 はディスパッチャーとして機能し、使用可能な容量がある場合は SSL トラフィックの一部を処理することもできます。CPU コア間で内部的にロード バランシングを行うシステムを使用することで、NSX Advanced Load Balancer は増え続けるキャパシティ全体で直線的にスケーリングできます。

メモリ

SE に割り当てられたメモリは、主に同時接続と HTTP キャッシュに影響します。メモリを 2 倍にすると、SE がこれらのタスクを実行する能力が 2 倍になります。デフォルトは 2 GB のメモリで、VMware クラウドのハイパーバイザー内で予約されます。予想される同時接続の詳細な説明については、「SE メモリ使用率」を参照してください。一般に、SSL 接続は HTTP レイヤー 7 接続の約 2 倍のメモリ、TCP プロキシを使用するレイヤー 4 の約 4 倍のメモリを消費します。

NIC

SE を介したスループットは、一括スループット、場合によっては SSL-TPS を制限する要因となります。SE のスループットは、プラットフォームによって大きく異なります。単一の SE で最大のパフォーマンスを得るには、DPDK をサポートできる Intel 10 Gb/s 以上の NIC を使用して、ベア メタルまたは Linux クラウド展開を使用することをお勧めします。

ディスク

SE は、インデックス作成のためにコントローラに送信される前に、ログをローカルに保存できます。ディスクを増やすと、SE で保持できるログの量が増えます。SSD は、ログ データをより高速に書き込むため、ハード ドライブよりも優先されます。

推奨されるストレージの最小サイズは、((2 * RAM)+ 5 GB) または 15 GB のいずれか大きい方です。VMware クラウドに展開される SE の場合、デフォルトは 15 GB です。

ログのディスク容量

NSX Advanced Load Balancerは、次のパラメータに基づいてログに使用できるディスク容量を計算します。

  • SE の合計ディスク容量。

  • SE CPU コアの数。

  • SE のメイン メモリ (RAM)。

  • SE でログに割り当てられていないディスク上の最大ストレージ(SE ランタイム プロパティを使用して構成可能)。

  • SE サイズに関係なくログに割り当てられる最小ストレージ。

デバッグ ログとクライアント ログに予約されている容量は、次のように計算できます。

  • デバッグ ログの容量 = (SE の合計ディスク * SE のログに割り当てられていない最大ストレージ容量)/ 100

  • クライアント ログの容量 = 合計ディスク – デバッグ ログの容量

これらの値の調整は、SE のログおよび RAM に割り当てられた最小ストレージの構成値に基づいて行われます。

PPS

PPS は通常、ハイパーバイザーによって制限されます。制限は、ハイパーバイザーとバージョンごとに異なります。ベア メタル(ハイパーバイザーなし)の PPS 制限は、使用する NIC のタイプと Receive Side Scaling (RSS) の利用方法によって異なります。

RPS(1 秒あたりの HTTP 要求数)

RPS は、CPU または PPS の制限に依存します。これは、CPU のパフォーマンスと、SE がプッシュできる PPS の制限を示します。

1 秒あたりの SSL トランザクション数

上記のハードウェア要因に加えて、TPS はクライアントと NSX Advanced Load Balancer 間の SSL セッションのネゴシエートされた設定によって異なります。SSL TPS に基づくサイジングで考慮すべきポイントは次のとおりです。

  • NSX Advanced Load Balancer は、RSA および楕円曲線 (EC) 証明書をサポートします。ネゴシエーション中に選択された暗号とともに使用される証明書のタイプによって、セッションを確立するための CPU コストが決まります。

  • RSA 2k キーは、EC に比べて計算コストが高くなります。NSX Advanced Load Balancer は EC に PFS を使用することをお勧めします。それによって、最高のパフォーマンスと可能な限り最高のセキュリティを実現できます。

  • RSA 証明書は、現在の業界標準をサポートしていないクライアントのバックアップとして引き続き使用できます。NSX Advanced Load Balancer は同じ仮想サービスで EC 証明書と RSA 証明書の両方をサポートするため、ユーザー エクスペリエンスへの影響を最小限に抑えながら EC 証明書を使用するように段階的に移行できます。詳細については、「EC 証明書と RSA 証明書の優先順位」を参照してください。

  • NSX Advanced Load Balancer のデフォルトの SSL プロファイルは、RSA よりも EC を優先し、非 PFS よりも PFS を優先します。

    さまざまなサイズのサービス エンジンでの RSA 証明書と EC 証明書のパフォーマンスの詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』の「NSX Advanced Load Balancerパフォーマンス データシート」のトピックを参照してください。

  • Perfect Forward Secrecy を使用する EC (ECDHE) は、PFS を使用しない EC (ECDH) よりも約 15% 高コストになります。

  • [SSL セッションの再利用]は、実際のワークロードに対する SSL パフォーマンスを向上させます。

  • TPS の数値を向上させるには、高速プロセッサ、仮想マシンに代わるベアメタル サーバを使用し、CPU コアを増やし、複数のサービス エンジン間で拡張します。SSL セッションの再利用により、実際のパフォーマンスが向上する可能性があります。

一括スループット

仮想サービスの最大スループットは、CPU と NIC またはハイパーバイザーによって決まります。

クライアントとサーバのトラフィックに複数の NIC を使用すると、輻輳や NIC の飽和の可能性を低減できます。仮想環境の 1 秒あたりの最大パケット数は大幅に異なり、トラフィックが SSL であるか暗号化されていない HTTP であるかに関係なく、同じ制限になります。

スループットの数値については、『VMware NSX Advanced Load Balancer インストール ガイド』の「インストールの準備」トピックの「パフォーマンス データシート」セクションを参照してください。SSL スループット数値は、データシートに記載されている標準暗号を使用して生成されます。より複雑な暗号や高コストの暗号を使用すると、スループットに悪影響を及ぼす可能性があります。同様に、RC4-MD5 などの安全性の低い暗号を使用すると、パフォーマンスは向上しますが、セキュリティ専門家によって推奨されません。

一般に、SSL 再暗号化が必要な場合、SE の CPU に対する TPS の影響は無視できます。これは、新しい SSL セッションを確立するための CPU コストのほとんどはクライアント側ではなくサーバ側で発生するためです。一括スループットの場合、SE の CPU への影響はこのメトリックの 2 倍になります。

同時接続(オープン接続とも呼ばれる)

SE のサイジングを計画するときに、同時接続の影響を見落としてはなりません。公表されている同時ベンチマークの数値は、一般にパススルー モードまたは非プロキシ モードのレイヤー 4 のものです。

言い換えれば、それらは達成可能なものよりも何桁も大きいということです。実際の SSL 終端接続ごとに、事前の保守的な見積もりとして、40 KB のメモリを考慮してください。HTTP ヘッダーのバッファリング、キャッシュ、圧縮、およびその他の機能の量は、最終的な数値に貢献します。同時実行性を高めるための最適化の方法など、詳細については、「SE メモリ使用率」を参照してください。

複数のサービス エンジンにわたるスケールアウト機能

NSX Advanced Load Balancer は、複数の SE 間でトラフィックをスケーリングすることもできます。スケールアウトにより、ワークロードを直線的にスケーリングできます。スケールアウトは、CPU、メモリ、PPS が制限要因になる場合に主に役立ちます。

NSX Advanced Load Balancer(L2 スケールアウト)のネイティブ自動スケール機能により、4 つの SE 間で仮想サービスをスケールアウトできます。ECMP スケールアウト(L3 スケールアウト)を使用すると、ワークロードを直線的にスケールして仮想サービスを複数の SE にスケールアウトできます。

次の図は、L2 スケールアウトを示しています。



スケールアウト機能の詳細については、「サービス エンジンの自動スケール」を参照してください。

サービス エンジンのパフォーマンス データシート

アプリケーションの動作と負荷要件に基づくサービス エンジンの上記の制限とサイジングの詳細については、パフォーマンス データシートを参照してください。

環境ごとにサイジングを行う際に考慮すべきポイントは次のとおりです。

  • vCenter Server と NSX-T Cloud

    • CPU 予約(se-group プロパティで構成可能)が推奨されます。

    • 負荷要件に基づく Vmware の RSS 構成。

  • ベアメタルおよび CSP(Linux サーバ クラウド)の展開

    • 単一の SE は、ベアメタルおよび CSP の Linux サーバ クラウド (LSC) 展開で最大 36 コアまで拡張できます。

    • 異なるクラウドでの PPS 制限は、使用されているハイパーバイザーまたは NIC、およびディスパッチャー コアと RSS の構成方法によって異なります。推奨される構成と機能のサポートの詳細については、「TSO、GRO、および RSS の構成」を参照してください。

  • SR-IOV および PCIe パススルーは、一部の環境で PPS の制限を回避し、ラインレート速度を提供するために使用されます。SR-IOV のサポートの詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』の「システム要件」トピックを参照してください。

  • パブリック クラウドのサイジングは、仮想マシン サイズごとのさまざまなクラウドでのクラウドの制限と SE のパフォーマンスに基づいて決定する必要があります。