技術概要：Citrix Virtual Apps and Desktopsサービスのローカルホストキャッシュ/高可用性モード
概要
ローカルホストキャッシュ（LHC）は、Citrix Virtual Apps and Desktops（CVAD）サービスのコンテキストで、保険契約と考えることができます。この保険契約は、何らかの理由（停止、接続の問題、インターネットの停電など）により、Citrix Cloud ConnectorがCitrix仲介サービス（CVADサービスの一部であり、それ以降、クラウドブローカー）と通信できない場合に適用されます。リソースの場所とクラウドブローカー間の通信が故障すると、エンドユーザーへの影響につながる可能性があります。ローカルホストキャッシュは、このようなエンドユーザーへの影響を軽減するように設計されています。
ローカルホストキャッシュは、クラウドブローカーへの接続を再確立できるようになるまで、仲介業務を引き継ぐ複数のサービスとコンポーネントの組み合わせです。
図 1: 高可用性モードに関連するコンポーネントを示すCVAD サービスの概念図
Cloud Connector コンポーネント
Citrix Cloud Connectorには、ローカルホストキャッシュ操作に必要なコンポーネントがいくつかあります。
- 構成シンクロナイザサービス: 構成シンクロナイザサービス (CSS) は、クラウドブローカーと (60 秒ごと) 定期的にチェックし、構成が変更されたかどうかを確認します。変更は、管理者が開始（デリバリーグループのプロパティの変更など）またはシステムアクション（マシンの割り当てなど）にすることができます。変更が検出されると、CSS はクラウドブローカーからコネクタマシンに変更を同期します。
- localDB: CSS は、Microsoft SQL Server Express の LocalDB データベースに構成データをインポートします。同期操作ごとに、データベースの新しいインスタンスが作成されます。同期が正常に完了すると、最新の DB インスタンスが以前の DB インスタンスと置き換えられます。
- 高可用性サービス : 高可用性サービス (HA サービス) は、停止中にランタイム仲介機能を提供する特殊なブローカーサービスです。HA サービスは、セカンダリブローカーとも呼ばれます。
-
リモートブローカープロバイダー: リモートブローカープロバイダーは、いくつかの重要な機能を実行します。
- これは、Citrix Virtual Delivery Agent（VDA）とクラウドブローカー間の通信を中継するプロキシとして機能します
- オンプレミスのStoreFront またはオンプレミスのADCとさまざまなCitrix Cloudサービス間の通信をプロキシリレーとして機能します
- リソースの場所を HA モードと通常動作の間で切り替えるタイミングを決定します
図 2: HA モードで機能するコネクタコンポーネントとサービス
Cloud Connectorマシンの適切なサイジングは、高可用性モード時にサービスに対して適切なリソースを使用できるようにするための重要なステップです。詳細については 、スケールとサイズに関する考慮事項の記事を確認してください 。
高可用性モード
Citrix Cloud Connectorは、管理者の介入なしに、高可用性モードを自動的に開始または終了できます。HA モードは、次のいずれかによってトリガーできます。
- StoreFront 列挙または起動要求の失敗
- VDAとクラウドブローカー間の通信の中継に失敗しました
- 起動時に、オンプレミスの ADC に代わってSecure Ticket Authority (STA) 要求を CVAD サービスに提示できない場合
HAモードでは、HAサービスはいくつかの重要な仲介機能を引き継ぎ、リソースを列挙し、ブローカーセッションを起動し、VDA登録を受け入れます。さらに、HA サービスは STA プロバイダーとして機能します。複数のCloud Connectorがあるリソースの場所では、 HAサービスは選挙プロセスの一環として相互に通信します。この選択プロセスは、HA モードがトリガーされた場合に HA サービスのどのインスタンスを引き継ぐかを決定します。
図 3: HA モードで動作しているリソースの場所
高可用性モードを開始/終了する
HA モードへの移行の決定は、特定の Cloud Connector インスタンスを通過する列挙トラフィックと起動トラフィックによって異なります。StoreFront でDelivery Controller として構成されているコネクタマシンのみが、高可用性モードの検出と移行をサポートします。この最適化は、不要なVDA登録を防ぐために必要です。
HA モードを開始および終了するサイクル全体では、いくつかの状態があります。正常動作状態では 、すべてのコンポーネントが正常であり、すべての仲介トランザクションはクラウドブローカーによって処理されます。CSS は、クラウドブローカーからコネクタマシンに構成をアクティブに複製しています。
一部のコンポーネントが正常なレポートに失敗した場合、コネクタは [ 保留中 HA ] 状態に移行します。この状態になると、包括的なヘルスチェックが開始され、次のアクションのコースが決定されます。コネクタは、リソースの場所にある他のコネクタと対話して、正常性のステータスを判断します。保留中の HA から [初期 HA] への移行の決定は、特定のリソースの場所にあるすべてのコネクタの健全性ステータスに基づきます。ヘルスチェックが成功すると、コネクタは正常動作状態に戻ります。または、ヘルスチェックが失敗し続ける場合、コネクタは [初期 HA] 状態に移行します。
図4：既存の高可用性モードを開始する場合のコネクタの状態
初期 HA 状態では、コネクタの高可用性サービスが仲介業務を引き継ぎます。クラウドブローカーに登録されたすべてのVDAは、コネクタのHAサービス/セカンダリブローカーに登録されます。初期 HA の終了時に、ヘルスチェックが開始されます。すべてのヘルスチェックが成功すると、状態は [保留中のリカバリ] に移行し、それ以外の場合は [拡張 HA] に移行します。
拡張された高可用性期間中はヘルスチェックが継続され 、すべてのヘルスチェックが成功すると、状態は [リカバリを保留中] に移行します。コネクタが拡張 HA 状態のままになるまでの最大時間はありません。
保留中の復旧は 、ブローカーをクラウドブローカーに返送する前に、すべてのコンポーネントが正常な待機期間として機能します。保留中のリカバリ中にいずれかのヘルスチェックが失敗すると、状態は拡張高可用性に戻ります。保留中の回復期間中にすべてのヘルスチェックが成功すると、状態は正常に動作している状態に移行します。この移行により、高可用性モードが終了し、セカンダリブローカーに登録されていたリソースの場所にあるすべてのVDAがクラウドブローカーに再登録されます。
複数のリソースロケーションを持つ CVAD サービスインスタンス
クラウドブローカーは、複数のリソースロケーションにまたがる展開全体のビューを持つように設計されています。ただし、高可用性モードでは、各リソースの場所は独自の独立したポッドになり、各リソースの場所で選択されたセカンダリブローカーは、そのリソースの場所内のVDAの仲介トランザクションのみを管理します。この設計は、VDAワークロードを含むすべてのリソースの場所からのすべてのCloud Connectorを含むようにStoreFront を構成するための重要な理由です。StStoreFront は、起動要求を分散し、複数のリソースの場所間で効果的にユーザーの負荷分散を行うことができます。
VDA登録
停止が始まると、選出されたセカンダリブローカー（選択プロセスの詳細については、 リソースの場所にある複数のコネクタに関するセクションを参照 ）には最新のVDA登録データがありませんが、VDAがVDAと通信すると、登録プロセスがトリガーされます。このプロセスの間、選択されたセカンダリブローカーは、そのVDAの現在のセッション情報も取得します。VDAは、少なくとも5分ごとにブローカーと通信します。最後のハートビートが完了した時期によっては、クラウドブローカーから選択されたセカンダリブローカーへの変更を実現し、選択したセカンダリブローカーへの登録がトリガーされるまでに最大5分かかることがあります。
選択されたセカンダリブローカーが接続を処理している間、リモートブローカープロバイダーはCitrix Cloudへの接続を監視します。接続が復元されると、リモートブローカープロバイダーは、選択されたセカンダリブローカーに接続情報のリッスンを停止するように指示し、クラウドブローカーへのブローカー操作の伝達を再開します。次回、VDAがリモートブローカープロバイダーと通信するときに、別の登録プロセスがトリガーされます。選択されたセカンダリブローカーは、以前の停止から残りのVDA登録をすべて削除します。CSSは、Citrix Cloudで構成が変更されたことを検出すると、情報の同期を再開します。
リソースロケーション内の複数のコネクタ
すべてのリソースの場所/ゾーンに少なくとも2つのコネクタを推奨します。各ゾーンでは、中断が発生した場合に仲介責任を引き継ぐコネクタマシンが HA サービスによって認識されるようにするために、選挙プロセスが絶えず実行されています。この選択は、通常の動作中と HA モードで実行しているときの両方で、常に実行されます。
CSS は、リソースの場所にあるすべてのCloud Connectorに関する情報を、セカンダリブローカーに定期的に提供します。これらの情報があれば、各コネクタはリソースの場所で実行されているすべてのピアコネクタを認識します。セカンダリブローカーは独立したチャネルで相互に通信します。これらのサービスでは、停止が発生した場合に、稼働しているマシンの FQDN 名のアルファベット順のリストを使用して、ゾーン内で選択されたセカンダリブローカーを特定します。高可用性モードでは、選択されたセカンダリブローカーが仲介業務を引き継ぐ一方、ゾーン内の他のセカンダリブローカーは着信接続要求とVDA登録要求をアクティブに拒否します。
停止状態中に、選出されたセカンダリブローカーに障害が発生した場合、別のセカンダリブローカーが選出されて処理を引き継ぎ、VDAは新しく選出されたセカンダリブローカーに登録されます。高可用性モード中に、コネクタが再起動された場合
- そのコネクタがセカンダリブローカーに選ばれていない場合、再起動しても影響はありません。
- そのコネクタがセカンダリブローカーとして選択された場合、別のCloud Connectorが選択され、VDAは新しい選択されたセカンダリブローカーに登録されます。再起動したCloud Connectorの電源がオンになると、このCloud Connectorが自動的に仲介処理を引き継ぐため、VDAはこちらのConnectorにもう一度登録されます。このシナリオでは、登録中にパフォーマンスに影響が生じることがあります。
イベントログには、選出に関する情報が含まれます。関連するイベントの詳細については、 製品ドキュメントのイベントログ記事を参照してください 。
複数のリソースの場所を持つローカルホストキャッシュ
リソースの場所にあるコネクタ間の負荷分散
オンプレミスのStoreFront は、デフォルトで60秒ごとにストアで構成されているすべてのCloud Connectorにハートビートメッセージを送信します。負荷分散アプリの列挙と起動要求では、正常な Cloud Connector (ハートビートに正常に応答する) のみが考慮されます。Cloud Connectorsへの同じハートビート要求によって、コネクタもアクティブになり、前のセクションで説明した HA モードアルゴリズムに参加します。すべてのリソースの場所の高可用性モードで実行できるようにするには、StoreFront oreFront構成でDelivery Controllerとして識別されたすべてのCloud ConnectorがオンプレミスのStoreFront にあることを確認することが重要です。適切なStoreFront 構成を使用しないと、サイトがHAモードになったときに容量が失われることがあります。
図 5: 構成が不足しているため、1 つの RL が HA 対応になっていない複数のリソースロケーションでの展開
同じアプリケーション/デスクトップを公開するリソースの場所の HA モード
CVAD サービス展開モデルの 1 つには、複数のリソースの場所が含まれます。すべてのリソースの場所で同一のアプリケーションとデスクトップを公開します。たとえば、単一のマルチセッションイメージまたはプールされた VDI デスクトップのアプリケーションを含む展開を、すべてのリソースロケーションに均一に展開できます。
このような展開がHAモードで動作している場合、ユーザーは、構成されたさまざまなリソースの場所にある任意のVDAに転送されます。このシナリオでは、StoreFront は、さまざまなリソースの場所で、構成されたすべてのCloud Connectorへの要求の負荷分散を行います。
さまざまなアプリケーション/デスクトップを公開するリソースの場所の HA モード
また、CVAD サービス展開では、特定のアプリケーションを、リソースの場所の特定のサブセットでのみ使用できます。たとえば、日本のOSデスクトップは、日本で実行されているVDAでのみ使用できます。別の例としては、静的/割り当て済みデスクトップがユーザー固有で、割り当て後に特定のリソースの場所に関連付けられます。
このような展開が HA モードで動作する場合、アプリケーションまたはデスクトップ起動要求は、アプリケーションおよびデスクトップが存在する特定のリソースの場所の適切な Cloud Connector にルーティングする必要があります。これは、クロスゾーン仲介が HA モードでは使用できないためです。StoreFront 1912 LTSR累積的な更新1またはそれ以降の機能によって提供されるAdvancedHealthCheck 機能は、次の段落で説明する展開などです。
StStoreFront は、任意の地域のCloud Connectorからアプリケーションとデスクトップを列挙します。列挙情報には、リソース (アプリケーションまたはデスクトップ) と、アプリケーション/デスクトップが存在するリソースの場所の間のマッピングが含まれます。このマッピングは、ユーザーの起動要求を特定のリソースの場所に送信するために使用されます。StoreFrontがこの機能を利用できるようにするには、 製品ドキュメントに記載されている構成手順を確認します 。
Citrix ADCが関与するアーキテクチャ
監視
Citrix ADCアプライアンスには、Citrix Virtual Apps and Desktops Delivery Controller サーバーを監視する組み込みのモニターであるCITRIX-XD-DDCモニターが用意されています。Citrix Virtual Apps and Desktops サービスのコンテキストでは、Cloud ConnectorはDelivery Controller サーバーと同等です。モニタは、設定済みのコントローラ/コネクタサーバにプローブを XML メッセージの形式で送信します。サーバーがファームの ID を使用してプローブに応答する場合、プローブは成功したとみなされ、サーバーのステータスは UP としてマークされます。応答に成功コードがない場合、またはサーバーファームの ID が応答に存在しない場合、プローブは失敗と見なされ、サーバーのステータスは DOWN としてマークされます。
CITRIX-XD-DDCモニターの詳細については、 Citrix ADC ドキュメントを参照してください。
異なるアプリケーション/デスクトップを公開するリソースロケーション用のCitrix ADC
異なるアプリやデスクトップを公開するリソースの場所を持つCitrix ADCを含むアーキテクチャでは、次の構成を実行する必要があります。
- 各リソースの場所にあるCloud Connectorを、ADC ロードバランサの一意の VIP に集約します。
- こちらの説明に従って 、 StoreFrontの高度なヘルスチェック機能を有効にします。
- 各ゾーン/リソースの場所をADC仮想IP（VIP）にマッピング
- すべてのADC VIPをデリバリーコントローラとしてStoreFront に追加します。
- CITRIX-XD-DDCモニタを介して各リソースの場所のCloud Connectorを監視するようにADCロードバランサーを設定します。
図6：複数のリソースロケーションとCitrix ADCを使用した展開
プールされたデスクトップVDAワークロードに関する考慮事項
ユーザーがプールされたデスクトップVDAからログオフすると、VDAのイメージがリセットされ、VDA上のユーザー固有のデータが削除されます。サイトが HA モードで実行されている場合、リセット操作は使用できません。したがって、ユーザーがプールされたデスクトップVDAからログオフすると、マシンはメンテナンスモードになります。このリセットにより、汚染されたイメージを別のユーザーが利用できるようになります。
実装のセキュリティニーズに応じて、サイト全体および配信グループごとの更新プログラムを適用することにより、この動作を変更できます。デフォルトの動作をオーバーライドする方法の詳細については、 製品ドキュメントを参照してください。
VMware vSphereおよびCitrix Hypervisorで実行されているプールされたデスクトップVDAワークロードでは、高可用性モード時の電源操作のサポートを導入する新機能が早期にプレビューできます。この機能により、サイトが HA モードで機能している場合でも、イメージをリセットする機能が追加されます。プレビューサービスの詳細については、 こちらをご覧ください。
ローカルホストキャッシュのテスト
ローカルホストキャッシュは、ユーザーの介入なしに動作するように設計されています–それは完全に自律です。ただし、すべての Cloud Connectorが正しく同期され、引き継ぐ準備ができていることを確認できます。次の手順を推奨します。
- 前のセクションで説明したように、すべてのコネクタはサイト構成の同期を個別に実行します。同期の結果は、イベントビューアに表示されます。 イベントの詳細については、製品ドキュメントの「イベントログ」セクションを参照してください 。
- 停止をシミュレートして、環境内のローカルホストキャッシュソリューションをテストできます。 停止を強制する方法に関するガイダンスは 、製品ドキュメントに記載されています。強制的に停止する場合は、リソースの場所にあるすべてのコネクタを強制停止モードに設定するように特に注意してください。