Citrix Virtual Apps and Desktopsゾーンについて詳しく見る
この記事では、Citrix Virtual Apps and Desktops環境でゾーンがどのように機能するかについて詳しく説明します。また、Delivery Controller、Hypervisor 接続、マシンカタログなどのアイテムを異なるゾーンに配置することによる影響についても説明します。まず、Citrix 製品ドキュメントのゾーンについて読むことをお勧めします 。
プライマリゾーンとサテライトゾーン
各サイトには、中央サイトデータベースと少なくとも2つのDelivery Controllerを含む1つのプライマリゾーンがあります。
セカンダリゾーンまたはサテライトゾーンには、1つ以上のVDA、コントローラー、StoreFront サーバー、およびNetScaler Gatewayが含まれます。通常の運用では、サテライトゾーンのControllerはプライマリゾーンの中央サイトデータベースと直接通信します。
プライマリゾーンのコントローラーは、サイトデータベースへの接続が良好で、すべてのサテライトゾーンにある程度接続されていることが前提となります。ただし、各サテライトゾーンの要素は、他のサテライトゾーンの要素に接続されているとは想定されていません。
ゾーンに関連付けることができる要素
配置内の複数の要素をサテライトゾーンに関連付けることができます。サテライトゾーンの要素は、サイトがそれらの要素やそれらに関連する他のオブジェクトとどのように相互作用するかに影響します。サテライトゾーンに配置できる要素は次のとおりです。
- コントローラーマシン
- ハイパーバイザー接続
- マシンカタログ
- NetScaler Gateway
Controllerマシンをサテライトゾーンに配置すると、それらのマシンは同じサテライトゾーン内のハイパーバイザーやVDAマシンへのローカル接続が良好であると見なされます。ローカル接続が良好であることを前提として、システムは、これらのハイパーバイザーとVDAマシンの処理にゾーン内のControllerを優先的に使用するように調整します。
ハイパーバイザー接続をサテライトゾーンに配置すると、そのハイパーバイザー接続で管理されるすべてのハイパーバイザーもそのサテライトゾーンに存在すると見なされます。そのハイパーバイザー接続との通信には、そのゾーンのコントローラーが優先されます。
同様に、マシンカタログをサテライトゾーンに配置すると、そのカタログ内のすべてのVDAマシンがサテライトゾーンにあることになります。各VDAを初めて登録すると、Controllerリストの自動更新メカニズムがアクティブになります。また、サテライトゾーンの配置によって、VDAがサイトに登録されるときにどのControllerが優先されるかが決まります。
VDAは、ローカルゾーン内のControllerに登録し、プライマリゾーンのControllerへの登録にフェイルオーバーすることを好みます。VDAは他のサテライトゾーンのControllerに登録されません。
NetScaler Gateway インスタンスはゾーンに関連付けることもできますが、Gatewayの関連付けは、ここで説明する他の要素と同様に、サイト構成の一部としてStoreFront の最適なHDXルーティング構成で作成されます。NetScaler Gatewayがゾーンに関連付けられている場合、そのゾーン内のVDAマシンへのHDX接続にはゾーンのゲートウェイが優先されます。
接続の質の制限
サテライトゾーンのControllerは、サイトデータベースに対してSQL操作を直接実行します。この SQL のやりとりを最小限に抑えるためにいくつかの変更が行われていますが、サテライトゾーンとデータベースを含むプライマリゾーンとの間のリンクの品質にはある程度の制限があります。一部の制限は、サテライトゾーンに展開されているVDAの数とこれらのVDA上のユーザーセッションの数に関係します。このため、VDAとセッションの数が少ないサテライトゾーンでは、VDAとセッションの数が多いサテライトゾーンよりもデータベースへの接続の質が低下します。いくつかのガイドラインを次に示します。
サポート対象のセッション数 | 想定されるエンドユーザーセッションの最大同時開始数 | 許容される最低帯域幅 | 許容される最大往復遅延時間 |
---|---|---|---|
50未満 | 20 | 1Mbps | 250ミリ秒 |
50–500 | 25 | 1.5Mbps | 100ミリ秒 |
500〜1,000 | 30 | 2Mbps | 50ミリ秒 |
1,000–3,000 | 60 | 8Mbps | 10ミリ秒 |
3,000以上 | 60 | 8Mbps | 5ミリ秒 |
ローカルホストキャッシュによる高可用性
ローカルホストキャッシュは、システムが停止した場合に、エンドユーザーへの新しい接続を仲介する高可用性を維持するのに役立ちます。ゾーンを使用している場合、データベースがプライマリゾーンにあるため、サテライトゾーンとプライマリゾーン間の通信が切断されると停止する可能性があります。この場合、サテライトゾーンのコントローラーはローカルホストキャッシュに切り替わり、エンドユーザーは引き続きアプリケーションやデスクトップへの新しい接続を仲介できます。ただし、これらのセッションを実行するVDAは、サテライトゾーンのControllerからアクセスできる必要があります。
他のタスクの中でも、Citrix Config Synchronizerサービス(CSS)は、ゾーン内のすべてのControllerに関する情報を高可用性サービスに定期的に提供します。この情報があれば、各高可用性サービスはピアとなるすべての高可用性サービスを把握できます。
High Availability Serviceは、独立したチャネルで相互に通信します。稼働しているマシンの FQDN 名のアルファベット順のリストを使用して、停止が発生した場合にゾーン内の操作を仲介する高可用性サービスを決定(選択)します。停止状態の間に、すべてのVDAが、選出されたHigh Availability Serviceに再登録されます。ゾーン内の選出されていない高可用性サービスは、受信接続およびVDA登録要求を積極的に拒否します。
選択した高可用性サービスが停止中に障害が発生した場合、別の高可用性サービスが引き継ぐように選択され、VDAは新たに選択された高可用性サービスに再登録されます。
停止状態中にControllerを再起動した場合:
- このControllerをプライマリブローカーに選出していない場合は、再起動しても影響はありません。
- このControllerをプライマリブローカーに選出している場合は、別のControllerが選出されてVDAはそちらに再登録します。再起動したControllerの電源がオンになると、このControllerが自動的にブローカーを引き継ぐため、VDAはもう一度再登録します。このシナリオでは、再登録中にパフォーマンスが影響を受ける可能性があります。
- プライマリブローカーに選出したControllerを、通常の操作中に電源を切ってから停止状態中に電源を入れると、ローカルホストキャッシュをこのController上で使用することはできません。
StoreFront展開環境
サテライトゾーンがプライマリゾーンから分離されているときに仲介機能の高可用性を利用したい場合は、各サテライトゾーンにStoreFront インスタンスを展開します。障害によりプライマリゾーンとサテライトゾーン間の接続が中断された場合、プライマリゾーンの1つのStoreFront インスタンスだけではサテライトゾーンのControllerにアクセスできないため、StoreFrontインスタンスはサテライトゾーンに必要です。
ゾーン数
サイトで多数のControllerを構成すると、サイト自体へのControllerの新規追加など一部の操作のパフォーマンスが低下する可能性があります。パフォーマンスの低下を避けるため、サイト内のゾーンの数は50以下に制限することをお勧めします。
低レベルの構成設定と調整
PowerShell SDK レベルでゾーンの定義を追加するなど、 ゾーンをサポートするためにいくつかの新しい構成項目が追加されました。これは、たとえば、ブローカーサービス SDKの一部ではなく、構成サービス SDKの一部です。ゾーン構成のその他の部分は、他の FMA サービス PowerShell SDK で実行できます。特に、要素がゾーンに関連付けられている場合、これらのオブジェクトのほとんどの所有権を持つサービスによって実行されます。そのため、マシンカタログのゾーンメンバーシップはBroker Service SDKを使用して定義され、ハイパーバイザー接続のゾーンメンバーシップはホストサービスSDKを使用して構成されます。
さらに、レジストリ設定を使用して、エンドユーザーによる同時起動のスロットリングを制御できます。レジストリ設定の主要部分はHKLM\\Software\\Citrix\\DesktopServer\\ThrottledRequestAddressMaxConcurrentTransactions
です。一部のテスト状況では、サテライトゾーンとプライマリゾーンのデータベース間の待ち時間が長く、サテライトゾーンでコントローラーを使用するエンドユーザーによるアプリとデスクトップ接続の起動率が比較的高いため、以前の起動が滞っていたために起動が遅れることがわかりました。
その他のヒント
サイトをアップグレードした後、Studioのゾーンノードが消えたという報告がいくつかあります。アップグレード中にロール構成ファイルをインポートできなかったために、ゾーンノードが消えることがあります。PowerShell SDK を使用してファイルをインポートすることで、失敗したインポートを手動で修正できます。
cd 'C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1\Citrix.XenDesktop.Admin\StudioRoleConfig'
Import-AdminRoleConfiguration –Path .\RoleConfigSigned.xml
<!--NeedCopy-->