App Volumes Manager のロード バランシング

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 にある場合があります。

高可用性

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 のロード バランシングのために選択した展開モデルによって異なります。 307 リダイレクト ソリューションを使用する 2 つの仮想サービスを備えた単一の VIP：Blast および PCoIP プロトコルは、NSX Advanced Load Balancer SE を通過するため、Blast および PCoIP のスループット用に SE のサイズを調整する必要があります。 307 リダイレクト ソリューションを使用する (n+1) VIP：NSX Advanced Load Balancer SE を通過するのは XML-API プロトコルであるため、必要な SE の数は少なくなります。 2 つの仮想サービスを備えた単一の VIP：Blast および PCoIP プロトコルは、NSX Advanced Load Balancer SE を通過するため、Blast および PCoIP スループット用に SE のサイズを調整する必要があります。 単一の L4 仮想サービス：Blast および PCoIP プロトコルは、NSX Advanced Load Balancer SE を通過するため、Blast および PCoIP スループット用に SE のサイズを調整する必要があります。 (n+1) VIP：NSX Advanced Load Balancer SE を通過するのは XML-API プロトコルのみであるため、必要な SE の数は少なくなります。 内部クライアントの DMZ にトラフィックが戻らないように、Connection Server のロード バランシングには個別の SE を使用することをお勧めします。 アクティブ/アクティブの高可用性構成には、少なくとも 2 つのサービス エンジンが必要です。 各サイトはその SE のサイズに合わせて調整する必要があり、サイト間の GSLB 要件に合わせて SE を追加します。

2 つの仮想サービスを備えた単一の VIP および単一の L4 仮想サービスのサイジングの例

例 1

250 ユーザーが小規模のワークロード（E メール、MS Office アプリケーション、複数のモニター）を行う単一のサイト。

いいえ。ユーザー数	ユーザーあたりのスループット（概算値）	スループット合計 =ユーザー数 x ユーザーあたりのスループット	アクティブ/アクティブ HA
250	600 Kbps	150 Mbps	1 コア SE x 2

例 2

1,500 ユーザーが中規模のワークロード（頻繁なファイル転送、複雑なドキュメント編集、480 p ビデオ、MS Office アプリケーション）を行う単一のサイト。

ユーザー数	ユーザーあたりのスループット（概算値）	スループット合計 = ユーザー数 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

5,000 ユーザーが中規模のワークロード（頻繁なファイル転送、複雑なドキュメント編集、480 p ビデオ、MS Office アプリケーション）を行う単一のサイト。

いいえ。ユーザー数	ユーザーあたりのスループット（概算値）	スループット合計 =ユーザー数 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