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 のロード バランシングのために選択した展開モデルによって異なります。

  1. 307 リダイレクト ソリューションを使用する 2 つの仮想サービスを備えた単一の VIP:Blast および PCoIP プロトコルは、NSX Advanced Load Balancer SE を通過するため、Blast および PCoIP のスループット用に SE のサイズを調整する必要があります。

  2. 307 リダイレクト ソリューションを使用する (n+1) VIP:NSX Advanced Load Balancer SE を通過するのは XML-API プロトコルであるため、必要な SE の数は少なくなります。

  3. 2 つの仮想サービスを備えた単一の VIP:Blast および PCoIP プロトコルは、NSX Advanced Load Balancer SE を通過するため、Blast および PCoIP スループット用に SE のサイズを調整する必要があります。

  4. 単一の L4 仮想サービス:Blast および PCoIP プロトコルは、NSX Advanced Load Balancer SE を通過するため、Blast および PCoIP スループット用に SE のサイズを調整する必要があります。

  5. (n+1) VIP:NSX Advanced Load Balancer SE を通過するのは XML-API プロトコルのみであるため、必要な SE の数は少なくなります。

  6. 内部クライアントの 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