アプリケーション配信タスクの実行中に、NSX Advanced Load Balancer SE は CPU、メモリ、または PPS リソースの枯渇に陥る可能性があります。ロード バランシングされた仮想サービスのキャパシティを増やすには、NSX Advanced Load Balancer は仮想サービス専用のリソースを増やす必要があります。
NSX Advanced Load Balancer Controller では、仮想サービスを未使用の SE に移行したり、仮想サービスを複数の SE 間でスケール アウトしてキャパシティをさらに増やしたりすることができます。これにより、複数のアクティブな SE が単一の仮想サービスのワークロードを同時に共有できます。
NSX Advanced Load Balancer データ プレーンのスケーリング方法
NSX Advanced Load Balancer は、データ プレーンのパフォーマンスをスケーリングするための 3 つの方法をサポートしています。
個々の SE パフォーマンスの垂直方向スケーリング
グループ内の SE のネイティブの水平方向スケーリング
グループ内の SE の BGP ベースの水平方向スケーリング
垂直方向スケーリングでは、SE を実行している仮想マシンに割り当てられているリソースを手動で増やし、その仮想マシンを再起動する必要があります。1 台の仮想マシンの物理的な制限に応じて、このスケーリングは制限されます。たとえば、SE は物理ホストで許可されている以上のリソースを消費することはできません。
水平方向スケーリングでは、仮想サービスは追加のサービス エンジンに配置されます。仮想サービスが配置される最初の SE は仮想サービスのプライマリ SE と呼ばれ、追加された SE はすべてセカンダリ SE と呼ばれます。
ネイティブ スケーリングを使用すると、プライマリ SE は仮想サービスのすべての接続を受け取り、すべてのセカンダリ SE にそれらの接続を分散します。その結果、すべての仮想サービス トラフィックがプライマリ SE を介してルーティングされます。ある時点で、プライマリ SE のパケット処理キャパシティが制限に達します。セカンダリ SE にキャパシティがあっても、プライマリ SE はそのキャパシティを利用するのに十分なトラフィックを転送できません。そのため、プライマリ SE のパケット処理キャパシティによって、ネイティブ スケーリングの有効性が決定されます。
たとえば、仮想サービスが 4 つの SE（1 つのプライマリ SE と 3 つのセカンダリ SE）にスケール アウトされると、プライマリ SE のパケット処理キャパシティは制限に達し、仮想サービスを 5 番目のサービス エンジンにスケール アウトしても得られるメリットはごくわずかです。
ネイティブ スケーリングの制限である 4 つのサービス エンジンを超えてスケーリングするために、NSX Advanced Load Balancer は BGP ベースの水平方向スケーリングをサポートしています。この方法は、RHI と ECMP に依存し、ロード バランシング インフラストラクチャを拡張するために手動の操作が必要です。詳細については、「仮想サービスをスケーリングするための BGP サポート」を参照してください。
両方の水平方向の方法を組み合わせて使用できます。ネイティブ スケーリングでは、最初の SE に変更を加える必要はありませんが、代わりに追加の SE への負荷分散が必要です。スケーリング キャパシティでは、ネットワークまたはアプリケーション内での変更は必要ありません。
サービス エンジンのネイティブ スケール アウト
通常の定常状態では、すべてのトラフィックを単一の SE で処理できます。この SE の MAC アドレスは、すべてのアドレス解決プロトコル (ARP) 要求に応答します。
トラフィックが単一の SE のキャパシティを超えると、NSX Advanced Load Balancer Controller は 1 つ以上の新しい SE を仮想サービスに追加できます。これらの新しい SE は、他の仮想サービス トラフィックを処理することも、このタスク用に新しく作成することもできます。既存の SE は数秒以内に追加できますが、新しい SE 仮想マシンのインスタンス化には、SE イメージを仮想マシンのホストにコピーするのに要する時間によっては数分かかる場合があります。
新しい SE が（ネットワークと構成の同期の両方のために）構成されると、プライマリと呼ばれる最初の SE は、一定の割合の受信クライアント トラフィックを新しい SE に転送し始めます。パケットはクライアントからプライマリ SE の MAC アドレスに送信され、新しい SE の MAC アドレスに（レイヤー 2 で）転送されます。このセカンダリ SE は、Transmission Control Protocol (TCP) 接続を終了し、接続と要求を処理してから、選択した宛先サーバに接続/要求をロード バランシングします。
セカンダリ SE は、フローを選択したサーバにロード バランシングするときに、その IP アドレスからトラフィックを送信元 NAT します。サーバは接続の送信元 IP アドレス (SE) に応答し、サーバから接続を所有する SE への対称リターン パスを確保します。
標準の Neutron を使用した OpenStack の場合、このような動作はセキュリティ違反になります。これを回避するには、ポート セキュリティを使用することをお勧めします。
SE からクライアントへ応答をルーティングする方法を管理者が直接制御する場合は、CLI（または REST API）を使用して、次に示すように
se_tunnel_mode設定を制御します。>configure serviceenginegroup Default-Group >serviceenginegroup> se_tunnel_mode 1 >serviceenginegroup> save
Tunnel モードの値は次のとおりです。
0（デフォルト）：ユーザー環境に基づいて自動
1：Tunnel モードを有効にする
2：Tunnel モードを無効にする
Tunnel モードの設定は、SE が再起動されるまで有効になりません。これはグローバルな変更です。
>reboot serviceengine
サービス エンジンのネイティブ スケール イン
このモードでは、NSX Advanced Load Balancer でロード バランサのロード バランシングを行うため、ネイティブの機能でキャパシティのオンザフライでの拡張または縮小ができます。
トラフィックをスケール インする場合、NSX Advanced Load Balancer はプロセスを反転し、アクティブな接続がタイムアウトするまでの時間としてデフォルトで 30 秒をセカンダリ SE に許可します。この期間が終了すると、セカンダリは残りの接続を終了します。これらの接続に対する後続のパケットは、プライマリ SE によって処理されます。または、仮想サービスが 3 つ以上の SE に分散されている場合、接続は残りの SE のいずれかにハッシュされる可能性があります。このタイムアウトは CLI コマンド vs_scalein_tmeout seconds を使用して変更することができます。
ディストリビューション
複数のサービス エンジンにわたってスケーリングすると、負荷の割合が完全に等しくならない場合があります。たとえば、プライマリ SE では、ロード バランシングの決定を行い、どの SE が新しい接続を処理するかを決定してから、入力方向のパケットを転送するようにしなければなりません。このため、セカンダリ SE よりもワークロードが高くなるため、セカンダリ SE よりも所有する接続の割合が少なくなる可能性があります。プライマリは、使用可能な CPU に基づいて、対象となる SE 全体のトラフィックの割合を自動的に調整します。
