Citrix Virtual Apps and Desktops: ゾーン、レイテンシー、仲介パフォーマンス

ゾーン

WAN で接続された広範囲に分散した場所に展開すると、ネットワークの遅延や信頼性の問題に直面する可能性があります。
複数のサイトを作成し、それぞれを個別に管理する必要のある独自の SQL Server サイトデータベースを使用するのではなく、1 つのサイト内にゾーンを構成できます。

仲介のパフォーマンスに対する遅延時間の影響

エンドユーザーは毎日リソースを起動します。ゾーンの追加により、ローカルブローカーが存在する限り、ユーザーはよりレイテンシーの高いリンクにアクセスできるようになりました。
余分なレイテンシーはエンドユーザーエクスペリエンスに影響を与えます。ユーザーが行うほとんどの作業で、サテライト・ブローカーと SQL データベース間のラウンドトリップに関連して予想される処理速度低下がわかります。

実際にセッションを仲介することには問題点があります。それは、アプリケーションを起動するVDAの負荷が最も低いVDAを選択する必要があるためです。
データベーストランザクション内で発生し、デリバリーグループ内のVDAの現在のすべての負荷のスナップショットが必要です。
デリバリーグループのすべてのワーカーがロック解除され、他のユーザーが同じロックを取ることができなくなります(シリアル化が発生します)。また、ワーカーの状態の変化 (セッションイベントなど) を待ってブロックします。

レイテンシーが低いと、ロックを取得してから解放するまでの遅延は小さくなります。ただし、レイテンシーが増加すると、ロックが保持される時間が長くなるため、セッションを仲介する時間が長くなります。

さまざまな種類のレイテンシーと起動率を調べてきました。
レイテンシーはラウンドトリップ時間(RTT)で、Verizon IPレイテンシー統計に基づいています。
ほとんどのRTTは記載されている最大値を下回っていますが、いくつかの有用な RTT でテストしていることを確認したかったのです。

往復時間は10ミリ秒(ms)で、ほとんどの国際遅延をカバーし、45ミリ秒は北米、ヨーロッパ、日本をカバーし、90ミリ秒は大西洋横断を、160ミリ秒は環太平洋、ラテンアメリカ、アジア太平洋地域では250ミリ秒、EMEAからアジア太平洋までは250ミリ秒です。

さまざまな種類の同時リクエストでテストし、12 から 60 までの値を 12 単位でテストしました。

注: テストは遅延がブローカーに与える影響に焦点を当てているため、VDAセッションはシミュレートされています。このテストでは、1つのデリバリーグループ内に57のVDAがあります。各テストでは、10,000人のユーザーを起動しようとしました。

10 ミリ秒の RTT 結果          
同時リクエスト 12 24 36 48 60
平均応答時間 (秒) 0.9 1.4 1.6 2.1 2.6
1秒あたりの仲介要求 14 17.8 22.9 23.2 22.9
エラー (% 年齢) 0 0 0 0 0
1万人のユーザーを起動するまでの時間 11m 57s 9m 24s 7m 16s 7m 11s 7m 17s

予想どおり、10 ミリ秒はシステムにかかる負荷を処理するのに十分な速さで、エラーはありませんでした。これはユーザーを起動する最も速い方法です。最大起動速度が60人の同時ユーザーの場合、平均応答時間は2.6秒で、10,000人のユーザー全員を起動するのに7分17秒かかりました。

45 ミリ秒の RTT 結果          
同時リクエスト 12 24 36 48 60
平均応答時間 (秒) 1.7 3.1 4.3 6.4 7.3
1秒あたりの仲介要求 7.1 7.8 8.4 7.5 8.2
エラー (% 年齢) 0 0 0 0.01 0.01
1万人のユーザーを起動するまでの時間 23m 28s 21m 19s 19m 51s 22m 15s 20m 19s

45ミリ秒でも、結果は良好でした。起動率が非常に高いと、1人か2人のユーザーがエラーに遭遇しました。

注: シリアル化の影響は、セッションを仲介する時間が1.7秒から7.3秒に増加したことで、応答時間に見られます。 10,000 人のユーザーを仲介する合計時間は 20 ~ 23 分でした。

90 ミリ秒の RTT 結果          
同時リクエスト 12 24 36 48 60
平均応答時間 (秒) 2.9 6.4 9.5 12.9 16.2
1秒あたりの仲介要求 4.1 3.7 3.8 3.7 3.7
エラー (% 年齢) 0 0 0 0.01 0.01
1万人のユーザーを起動するまでの時間 40m 30s 44m 29s 44m 11s 44m 55s 45m 04s

90 ミリ秒の結果では、エラーはほとんど発生しませんでした。
トランザクションがレイテンシーに与える影響は、ユーザーが12件の同時リクエストがあるセッションを仲介するのに許容できる平均時間が2.9秒で、60件の同時リクエストがあるセッションを仲介する場合は許容できない16.2秒に増加すると、より明白になります。
この場合、より低いレートでユーザーを仲介する方が有利です。10,000 人のユーザー全員を起動するのに 40 ~ 45 分かかりました。

160 ミリ秒の RTT 結果          
同時リクエスト 12 24 36 48 60
平均応答時間 (秒) 5.7 11.4 17.3 23.2 28.0
1秒あたりの仲介要求 2.1 2.1 2.1 2.1 2.1
エラー (% 年齢) 0 0 0.12 4.0 17.7
1万人のユーザーを起動するまでの時間 1 時間 19 分 0 秒 1 時間 19 分 27 秒 1 時間 19 分 55 秒 1 時間 20 分 26 秒 -

160 ミリ秒になると、起動率が高くなると重大なエラーが発生し始め、48 件のリクエストで 4%、60 リクエストで 17.7% のエラーが発生し、応答時間も 30 秒に近づきます。
ただし、最大36リクエストの場合、エラー率は0.1%で、平均仲介時間は17秒です。

注: 60 個のリクエストの起動時間を判断するのは困難です。17% の失敗を考慮に入れるのは難しいからです。

このレイテンシーを考慮すると、24 件の同時リクエストを渡さないことをお勧めします。また、サイトのサイズも要因となる可能性があります。1,000人のユーザーを立ち上げるには約8分かかります。これにより、ユーザー数が 10,000 人の場合は 1 時間 20 分までスケールアップできます。そのため、データベースに対してこのレベルの遅延が発生する大規模なサイトはお勧めしません。

250 ミリ秒の RTT 結果          
同時リクエスト 12 24 36 48 60
平均応答時間 (秒) 9.3 15.4 26.7 - -
1秒あたりの仲介要求 1.3 1.6 1.3 - -
エラー (% 年齢) 0 0 4.6 42.8 99.0
1万人のユーザーを起動するまでの時間 2時間 8分 33秒 1時間 46分 52秒 2時間 3分 46秒 - -

このように待ち時間が長いと、同時起動率が高くなると多くのタイムアウトが発生しました。48件のリクエストでは、42.8パーセントのリクエストが失敗しました。リクエストが 60 件になると、タイムアウトが頻繁に発生し、リクエストの 99% が失敗したため、サイトが使用できなくなりました。許容できる起動率は、12 リクエストと 24 リクエストのみでした。このレベルのレイテンシーで大規模なサイトをデプロイすることはお勧めできません。1,000人のユーザーの起動には、12の同時リクエストで13分、24の同時リクエストで11分かかりました。10,000 人のユーザーの場合、最大 2 時間 8 分かかります。

スロットリングリクエスト

高レイテンシーで作業する必要があり、タイムアウトが多すぎる場合は、XenAppとXenDesktop 7.7にレジストリキーが追加され、一定数の同時仲介要求のみを処理できるようになりました。StoreFront は、制限を超えるリクエストを数秒後に再試行します。これはリクエストをバックオフするのに役立ち、ロックキューイングを減らすことができます。ただし、ユーザーによっては、常に運が悪く、リクエストが常に取り消されるため、起動時間が長くなる場合があります。

キーは DWORD で、次の場所に保存する必要があります。HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions

キーが存在しない場合、仲介リクエストに制限はありません。

注: キーはDelivery Controller ごとに設定されるため、SQL Server上のリクエストの合計をリモートコントローラ間で分割する必要があります。

まとめ

仲介はレイテンシーよりも機能しますが、リモートゾーンのサイジングにはレイテンシーを考慮する必要があります。ゾーンが大きい場合でも、そのゾーンのローカルデータベースを維持することが望ましい場合があります。ゾーンが小さい場合は、リモートゾーンを使用するとうまく機能し、エンドユーザーエクスペリエンスに影響を与えずに管理コストを削減できます。

各ゾーンのRTTは250ミリ秒未満にすることをお勧めします。それを超える場合は、別のサイトを設定することを検討してください。

この記事は、Chris Gilbert によって書かれたブログ記事から変更されました。元のブログを読んだり、コメントを確認したりするには、 https://www.citrix.com/blogs/2016/02/09/zones-latency-and-brokering-performance-2/にアクセスしてください。

Citrix Virtual Apps and Desktops: ゾーン、レイテンシー、仲介パフォーマンス