NSX Advanced Load Balancer は、複数の仮想サービスが同じ IP アドレスを共有し、リスナー ポートが異なる場合に VIP 共有をサポートします。このセクションでは、異なるスケールアウト モードでの共有仮想サービス IP (VIP) の動作について説明します。
仮想サービス 1 について考えます。 VIP=1.1.1.1, port=80 仮想サービス 2: VIP=1.1.1.1, port=443
NSX Advanced Load Balancer 配置ロジックは、これらの仮想サービスを同じサービス エンジンのセットに配置するように制限されています。これは、この IP アドレスに対してアドバタイズできるプライマリ サービス エンジンが 1 つのみであるためです。プライマリ サービス エンジンに障害が発生した場合は、プライマリ サービス エンジンのロールを引き継ぐ同じセカンダリ サービス エンジンで仮想サービスを有効にする必要があります。
スケールアウト モード
NSX Advanced Load Balancer が L2 スケールアウト モードで動作する場合（VMware、OpenStack、AWS、Linux サーバ クラウドなどの多くの環境が該当します）、プライマリ サービス エンジンは、VIP をアドバタイズし、セカンダリ サービス エンジンにトラフィックをパントします。
NSX Advanced Load Balancerで動作する場合、BGP、ECMP などの L3 スケールアウト モードが使用されます。これは、BGP が有効になっている Azure、GCP、Linux サーバ クラウドなどの環境の場合、ネクスト ホップ ルーター/ロード バランサは、仮想サービス IP アドレスをアドバタイズするサービス エンジンへのフローベースのハッシュを行います。
レイヤー 2 スケールアウト モードの共有 VIP
VIP を共有する各仮想サービスは個別にスケールアウトでき、NSX Advanced Load Balancer Controller はそれらを同じサービス エンジンのセットに配置し、仮想サービスをホストしているサービス エンジンのセットにのみフローを配分します。
レイヤー 3 スケールアウト モードの共有 VIP
VIP を共有する各仮想サービスを個別にスケール アウトすることはできません。トラフィックが正しく機能するには、同じ数の SE にスケーリングする必要があります。
1 つの仮想サービスで実行されるスケールアウト/スケールイン操作は、VIP を共有する他のすべての仮想サービスに均等に適用する必要があります。
1 つの仮想サービスで実行された移行は、VIP を共有する他の仮想サービスに自動的に適用されます。
キャパシティ の SE での共有 VIP 仮想サービスの配置
同じ SE 上の既存の仮想サービスと VIP を共有する完全な SE への新しい仮想サービスの配置（max_vs_per_se に到達）は、NSX Advanced Load Balancer でブロックされました。これにより、共有 VIP 設定に非対称性が生じる可能性があります。ECMP ベースのスケールアウト展開の場合、非対称にスケールアウトされた共有仮想サービスによってトラフィックが失われます。
共有仮想サービスの max_vs_per_se 制限が緩和されました。
シナリオ |
以前の動作 |
新しい動作 |
|---|---|---|
 仮想サービス 1b が作成/有効になり、仮想サービスが同じ SE に確実に配置されるように、SE 1 に配置する必要があります。 |
VS 1b が |
仮想サービス 1b を SE 1 に配置します。このシナリオは、兄弟 VS1a を持つ SE にキャパシティがない場合に仮想サービスを配置しようとするパック アルゴリズムの新しい動作をトリガします。 |
 VS 1a と VS 1b の両方が同時に有効になります。 |
VS 1a が |
VS 1a を SE 1 に配置し、VS 1b を SE 1 に配置します。このシナリオでは、パックされたアルゴリズムの新しい動作がトリガされます。SE グループが新しい SE を作成できず（ |
 VS 1a は SE 1 および SE2 にスケール アウトされ、VS 1b が作成/有効になります。 |
VS 1b は SE 1 に配置されます。 |
VS 1b は SE 1 に配置されます。 また、L3 スケールアウトでは、VS 1a と VS 1b の両方で障害が発生し、非対称性が強調表示されます。つまり、仮想サービス 1a は SE 1 にのみ配置され、仮想サービス 1b は SE 1 と SE 2 に配置されます。 ケース 3 の VS 1a および VS 1b で発生した障害は次のようになります。 障害 1: VS 1a の場合 — 仮想サービスは VsVIP を 2 つの仮想サービスと共有しており、非対称にスケール アウトされます。VIP 1 の場合、この仮想サービスには 2 つのサービス エンジンがあり、共有仮想サービス VS 1b のサービス エンジンは少なくなります。 障害 2:VS 1b の場合:VirtualService は VsVIP を 2 つの仮想サービスと共有しており、非対称にスケール アウトされます。VIP 1 の場合、この仮想サービスには 1 つのサービス エンジンがあります。共有仮想サービス VS 1a には、より多くのサービス エンジンがあります。 |
VS 1a は SE 1 および SE 2 にスケール アウトされ、VS 1b が作成/有効になります。 |
VS 1b は SE 1 にのみ配置されます |
VS 1b は SE 1 にのみ配置されます |
ECMP ベースのスケールアウトの場合、非対称性が検出されるたびに、共有 VIP セット内のいずれかの仮想サービスがセット内の他の仮想サービスよりも多くの/少ない SE にスケール アウトされると、すべての共有 VIP 仮想サービスで障害が発生します。
この変更は、パック配置アルゴリズムで最も顕著に見られます。ここでは、SE グループで max_se に達し、一部の SE が max_vs_per_se に達するシナリオでの共有仮想サービスの配置に対応するための最適化が行われています。
コントローラは、現在 SE に存在する、または存在しないすべての共有仮想サービスを追跡するため、バッファ SE の計算は、SE グループ内の各 SE に存在する仮想サービスの数の増加に対応しようとします。
次のイメージは、非対称スケール アウト中に発生した障害を示しています。
OpenStack の VIP 配置の詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』の「OpenStack クラウドの高度な構成」を参照してください。
