実際のワークロードに応じて、SE グループ レベルの構成を使用して、NSX Advanced Load Balancer SE 設定を微調整できます。

SE のキャパシティを計画する際に従うガイドラインは次のとおりです。

一般的なガイドライン

一般的なガイドラインは次のとおりです。

  • NSX Advanced Load Balancer SE 仮想マシンでは、一貫した予測可能なパフォーマンスを実現するために、CPU とメモリを予約することが推奨されます。

  • SE 上の仮想サービス配置用の NSX Advanced Load Balancer SE グループ設定でコンパクト モードを使用します。これにより、NSX Advanced Load Balancer が仮想サービスの配置に必要な最小数の SE を使用するように確保します。これは、パブリック クラウドの使用事例の場合にコストを節約するのに役立ちます。

ディスパッチャーの構成

ディスパッチャーの構成は次のとおりです。

  • デフォルトでは、dedicated_dispatcher は SE グループ レベルで False に設定されています。この構成は、1 コアや 2 コアなど、コンピュータのキャパシティが小さい SE に最適です。

  • NSX Advanced Load Balancer では、2 コアを超える SE サイズの場合、dedicated_dispatcher を True に設定することをお勧めします。

GRO および TSO の構成

GRO および TSO の構成は次のとおりです。

  • GRO のデフォルト設定は無効で、TSO の場合は有効です。この構成は、ほとんどのワークロードで正常に機能します。

  • GRO は、十分なディスパッチャー（4 つ以上）があり、その使用率が低い場合にいつでも有効にできます。

Receive Side Scaling の構成

Receive Side Scaling (RSS) の構成は次のとおりです。

  • RSS を有効にしてパフォーマンスを向上させることができます。RSS は、NIC あたりのディスパッチャーとキュー数が多いほど、より優れた PPS を実現できます。

  • ディスパッチャーの数は 2 の累乗でのみ設定できます。つまり、ディスパッチャーの数は 1、2、4、8 などになります。

  • max_queues_per_vnic のデフォルト値は 1 です。値を 0 に設定すると、構成されたディスパッチャー数に基づいてキューの数が自動的に決定されます。この値は、要件に従って設定できます。

  • NIC ごとに使用可能なキューの数がディスパッチャーよりも少ない場合、ディスパッチャーの数はキューの数に合わせて調整されます。ディスパッチャーの数を使用可能なキューの数よりも大きくすることをお勧めします。

データパス隔離

遅延およびジッターの影響を受けやすいアプリケーションに対して SE データパス隔離を有効にできます。この機能は、データパスと制御プレーンの SE 機能用に 2 つの独立した CPU セットを作成します。

パブリック クラウドでの自動 RSS の推奨事項

すべての NSX Advanced Load Balancer パブリック クラウド インスタンスは、SE グループの max_queues_per_vnic および num_dispatcher_cores ノブの適切な値を設定することで自動 RSS を有効にできます。自動 RSS の構成の詳細については、「TSO GRO RSS の構成」を参照してください。

RSS が有効で、インスタンスの vCPU の数が 8 以上であるすべてのインスタンスについて、SE グループの dedicated_dispatcher_core ノブを使用して専用のディスパッチャーを設定することをお勧めします。専用ディスパッチャーはランタイム プロパティであり、再起動は必要ありません。

さまざまなワークロードに対する推奨事項

さまざまなワークロードに対する推奨事項は次のとおりです。

  • ファイルの GET が小さく 1 秒あたりの接続数が多いなど、PPS 負荷が高い場合は、より高い PPS を実行するためにより多くのディスパッチャーが必要です。

  • SSL トランザクションが多いワークロードはプロキシの負荷が大きく、プロキシ コアの数が多い場合にメリットがあります。

  • 1 コア SE および 2 コア SE にはデフォルト設定が推奨されます。

次の例では、vCenter Server フル アクセス クラウドで実行されている 6 コア SE の構成の推奨事項について説明します。

1 - PPS トラフィックの多いプロファイル

TCP を使用した 100 のレイヤー 4 仮想サービスがあり、1 秒あたり平均 1,000 の新しい TCP 接続を実行し、各接続は 3 秒間持続し、1 つの GET 要求で 1 つの小さなファイルをダウンロードする場合を想定します。

フロントエンドとバックエンドの両方で TCP トランザクションごとに 18 ～ 20 パケットを考慮すると、この要件は新しい TCP 接続の 1 秒あたり約 100 万のパケットに相当します。パケットの量を考慮すると、NSX Advanced Load Balancer SE を次のように構成する必要があります。

  • 専用のディスパッチャー：True

  • ディスパッチャーの数：2

  • プロキシ コアの数：4

  • NIC あたりのキュー数：2

2 – SSL スループットと TPS トラフィックの多いプロファイル

複数の SSL アプリケーションが 1 秒あたり合計 2,000 の ECC トランザクションを実行し、GET の SSL スループットが 2 Gbps であると仮定します。

上記の要件では、1 秒あたりのパケット数がそれほど高くないため、ディスパッチャー コアはビジーになりません。SSL 処理は ECC トランザクションとスループットを実行するためにプロキシ コアを消費します。RSS はこの使用事例では役に立ちません。ワークロードに対する推奨事項は以下のとおりです。

  • 専用のディスパッチャー：True

  • ディスパッチャーの数：1

  • プロキシ コアの数：5

  • NIC あたりのキュー数：1

3 – IP ルーティング トラフィックが 50% を占める HTTP ワークロード

IP ルーティング トラフィックが 50% を占める単一の SE で、1 秒あたり 150 万のパケットで約 5 ～ 6 Gbps を実行する複数の L7 アプリケーション。アプリケーションの実行は遅延とジッターの影響を受けます。

上記の要件を達成するため、NSX Advanced Load Balancer では SE コアの 1 つをデータパス以外のタスク専用にすることを推奨します。これは、次の構成で実現できます。

  • 専用のディスパッチャー：True

  • se_dp 分離モード：True

  • dp 以外のコア数：1

  • ディスパッチャー コアの数：2

  • NIC あたりのキュー数：2

  • プロキシ コアの数：3