App Volumes Manager のロード バランシングは、HTTPS アプリケーション プロファイルを使用して L7 仮想サービスを構成することで実現できます。
App Volumes サーバは、異なる送信元 IP アドレスからの同じクライアントの接続をサポートしません。仮想サービスがアクティブ/アクティブ スケールアウトとして展開されている場合、同じクライアントからの複数の接続が異なるサービス エンジンによって処理される場合があります。各サービス エンジンは個別の SNAT IP アドレスを使用するため、サーバが、異なる送信元 IP アドレスから同じクライアントへの接続を複数検出し、結果的に認証に失敗することがあります。この問題に対処するには、次のいずれかのオプションを使用します。
オプション 1:App Volumes をロード バランシングする際に、アクティブ/スタンバイ サービス エンジン グループを使用する
オプション 2:ネイティブ スケールアウトを使用している場合は、CLI を使用して、クライアント IP アドレスとポートではなく、クライアント IP アドレスのみに基づくフロー分布アルゴリズムを構成する
configure virtualservice <appvol-vs-name> flow_dist flow_dist consistent_hash_source_ip_address save
オプション 2 は、ネイティブ スケールアウトの場合にのみ適用されます。ECMP スケールアウトが使用されている場合(BGP など)、サービス エンジン間のフロー分布は、アップストリーム ルーターで使用される ECMP ハッシュ アルゴリズムに依存します。そのハッシュが完全な 5-tuple(送信元/宛先 IP アドレス/ポート/プロトコル)に基づいている場合、この問題が発生します。
GSLB を使用したマルチサイト
NSX Advanced Load Balancer は、トラフィックを必要なサイトに送信するため、任意のロード バランシング アルゴリズム(位置情報、送信元 IP アドレス ベースなど)を使用して GSLB とともに構成することができます。これにより、地理的に同じ位置にあっても、East-West トラフィックが回避されます。サイト 1 は任意のエコシステムにあり、サイト 2 のエコシステムとは異なる場合があります。たとえば、サイト 1 はオンプレミスにあり、サイト 2 は VMC にある場合があります。
![](images/GUID-61440C3F-422C-4879-AB65-11F20425D858-high.png)
高可用性
NSX Advanced Load Balancer サービス エンジンは、Elastic HA アクティブ/アクティブ モードで展開することをお勧めします。アクティブ/アクティブの高可用性展開モードでは、仮想サービスは両方のサービス エンジンに配置されます。したがって、一方のサービス エンジンの障害は、その特定の SE を通過するユーザー トラフィックにのみ一時的に影響します。詳細については、『VMware NSX Advanced Load Balancer 構成ガイド』の「高可用性と冗長性」トピックを参照してください。
最高のパフォーマンスを得るには、Horizon 用に個別の NSX Advanced Load Balancer SE を使用することをお勧めします。同じ SE に他の仮想サービスを配置しないでください。
サイジングに関する考慮事項
NSX Advanced Load Balancer Controller のサイジング |
本番環境用に構成されたクラスタ内に 3 つのコントローラを配置することをお勧めします。NSX Advanced Load Balancer Controller には、CPU、RAM、およびストレージの最小仕様が必要です。サイジングのガイドラインの詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』の「NSX Advanced Load Balancer Controller のサイジング」のトピックを参照してください。 |
NSX Advanced Load Balancer SE のサイジング |
Horizon 環境の場合、SE のサイジングはユーザー数とユーザーあたりのスループットによって異なります。ビデオや 3D モデリングなど大きい帯域幅を必要とするアプリケーションでは高いスループットが必要になるため、SE のサイジングは VDI 経由でアクセスされるアプリケーションにも依存します。スループットを決める最大の要因は、セカンダリ プロトコル (Blast/PCoIP) です。 SE の数は、以下で説明するように、UAG のロード バランシングのために選択した展開モデルによって異なります。
アクティブ/アクティブの高可用性構成には、少なくとも 2 つのサービス エンジンが必要です。 各サイトはその SE のサイズに合わせて調整する必要があり、サイト間の GSLB 要件に合わせて SE を追加します。 |
2 つの仮想サービスを備えた単一の VIP および単一の L4 仮想サービスのサイジングの例
例 1
いいえ。ユーザー数 |
ユーザーあたりのスループット(概算値) |
スループット合計 =ユーザー数 x ユーザーあたりのスループット |
アクティブ/アクティブ HA |
---|---|---|---|
250 |
600 Kbps |
150 Mbps |
1 コア SE x 2 |
例 2
ユーザー数 |
ユーザーあたりのスループット(概算値) |
スループット合計 = ユーザー数 x ユーザーあたりのスループット |
アクティブ/アクティブ HA |
---|---|---|---|
1500 |
2 Mbps |
3 Gbps |
2 コア SE x 2 |
Example 3
1,000 人のユーザーが高ワークロード(3D モデリング、高解像度ビデオ、3D グラフィックス)を行う単一のサイト。
ユーザー数 |
ユーザーあたりのスループット(概算値) |
スループット合計 = ユーザー数 x ユーザーあたりのスループット |
アクティブ/アクティブ HA |
---|---|---|---|
1000 |
20 Mbps |
20 Gbps |
4 コア SE x 4 |
ビデオまたはジッターの影響を受けやすいアプリケーションの場合は、最適なパフォーマンスを得るために、専用のディスパッチャを使用することをお勧めします。
ビデオなどの高帯域幅を必要とするアプリケーションの場合は、最適なパフォーマンスを得るために、L3 スケールアウトをお勧めします。
例 4
いいえ。ユーザー数 |
ユーザーあたりのスループット(概算値) |
スループット合計 =ユーザー数 x ユーザーあたりのスループット |
アクティブ/アクティブ HA |
---|---|---|---|
5000 |
2 Mbps |
10 Gbps |
3 コア SE x 2 |
より高い PPS でパフォーマンスを向上するには、専用のディスパッチャを使用することをお勧めします。
例 5
10000 ユーザーが小規模のワークロード(E メール、MS Office アプリケーション、複数のモニター)を行う単一のサイト。
いいえ。ユーザー数 |
ユーザーあたりのスループット(概算値) |
スループット合計 =ユーザー数 x ユーザーあたりのスループット |
アクティブ/アクティブ HA |
---|---|---|---|
10000 |
600 Kbps |
6 Gbps |
2 コア SE x 2 |
単一サイトのサイジング リファレンスのサマリは、次のとおりです。
ユーザーあたりのスループット |
小(ユーザーあたり最大 600 kbps) |
中(ユーザーあたり最大 2 Mbps) |
大(ユーザーあたり最大 20 Mbps) |
---|---|---|---|
100 |
1 コア x 2 SE |
1 コア x 2 SE |
1 コア x 2 SE |
700 |
1 コア x 2 SE |
1 コア x 2 SE |
4 コア x 3 SE |
1000 |
1 コア x 2 SE |
1 コア x 2 SE |
4 コア x 4 SE(L3 スケールアウトを推奨) |
5000 |
2 コア x 2 SE |
4 コア x 2 SE |
4 コア x 16 SE(L3 スケールアウトが必要) |
10000 |
2 コア x 2 SE |
4 コア x 4 SE(L3 スケールアウトを推奨) |
4 コア x 32 SE(L3 スケールアウトが必要) |
n+1 VIP のサイジングの例
ユーザー数 |
SE の数 |
---|---|
最大 1000 ユーザー |
1 コア * 2 SE |
1,000 ~ 5,000 ユーザー |
2 コア * 2 SE |
5,000 ~ 10,000 ユーザー |
3 コア * 2 SE |
Connection Server のロード バランシングのサイジング例
ユーザー数 |
SE の数 |
---|---|
最大 1,000 ユーザー |
1 コア * 2 SE |
1,000 ~ 5,000 ユーザー |
2 コア * 2 SE |
5,000 ~ 10,000 ユーザー |
3 コア * 2 SE |
GSLB を使用したサイジング
GSLB では、サイトごとに 1 つの SE が必要です。Horizon 用 GSLB の場合は、1 コア SE にすることができます。たとえば、サイト 1 に、小規模のワークロード(E メール、MS Office アプリケーション、複数のモニター)を行う 250 人のユーザーがいるとします。サイト 2 には、高ワークロード(3D モデリング、ハイ デフ ビデオ、3D グラフィックス)を行う 250 人のユーザーがいます。
サイト |
ユーザー数 |
ユーザーあたりのスループット(概算値) |
スループット合計 = ユーザー数 x ユーザーあたりのスループット(ユーザーあたり最大 20 Mbps) |
アクティブ/アクティブ HA の SE の数 |
GSLB |
---|---|---|---|---|---|
サイト 1 |
250 |
600 Kbps |
150 Mbps |
1 コア SE x 2 |
1 コア SE |
サイト 2 |
250 |
600 Kbps |
150 Mbps |
1 コア SE x 2 |
1 コア SE |
合計コア数 = 6 |
4 |
2 |