ローカルホストキャッシュ
ローカルホストキャッシュを使用すると、Cloud ConnectorがCitrix Cloudと通信できなくなった場合でも、Citrix DaaS(旧称Citrix Virtual Apps and Desktopsサービス)環境での接続仲介操作を続行できるようになります。ローカルホストキャッシュは、ネットワーク接続の切断時間が60秒に達すると作動します。
ローカルホストキャッシュがあれば、接続済みのユーザーは、停止状態が発生した場合も途切れることなく作業を続行できます。再接続時および新規接続時の接続遅延は最小限に抑えられます。
重要:
ローカルホストキャッシュを使用するには、展開の一部として、顧客が展開したオンプレミスのStoreFrontが必要です。VDAが登録されている(または登録できる)すべてのCloud Connectorを、Delivery ControllerとしてStoreFrontに追加する必要があります。StoreFrontに追加されていないCloud Connectorは停止モードに移行できないため、ユーザーの起動に失敗することがあります。
オンプレミスのStoreFrontを使用しない展開の場合は、Citrix Workspaceプラットフォームのサービス継続性機能を使用して、ユーザーが停止中にリソースに接続できるようにします。詳しくは、「サービス継続性」を参照してください。
データコンテンツ
ローカルホストキャッシュには、メインデータベースの情報の一部として次の情報が格納されます:
- サイトから公開されたリソースに対する権限が割り当てられているユーザーおよびグループのID。
- サイトの公開リソースを現在使用しているか、最近使用したユーザーのID。
- サイトで構成されているVDAマシン(リモートPCアクセスマシンを含む)のID。
- 公開リソースへの接続で頻繁に使用されているCitrix WorkspaceアプリクライアントマシンのID(名前とIPアドレス)
また、メインデータベースが利用できなくなったときに確立され、現在アクティブな接続に関する情報も格納されています:
- Citrix Workspaceアプリで実行されたクライアントマシンエンドポイント分析の結果
- サイトに関連するインフラストラクチャマシン(Citrix GatewayやStoreFrontサーバーなど)のID
- ユーザーによる最近のアクティビティの日時とタイプ
機能
ローカルホストキャッシュがCitrix Cloudとどのように相互作用するかを表示します。
通常の操作中
- Cloud Connector上のプリンシパルブローカー(Citrix Remote Broker Provider Service)は、StoreFrontからの接続要求を受け取ります。プリンシパルブローカーは、Citrix Cloudと通信して、Cloud Connectorに登録済みのVDAにユーザーを接続します。
- Citrix Config Synchronizer Service(CSS)は、Citrix Cloudのブローカーを毎分チェックして、構成に変更がないか確認します。こうした変更には、管理者によるもの(デリバリーグループのプロパティの変更など)とシステム操作(マシン割り当てなど)があります。
-
前回のチェック以降に構成が変更された場合、CSSは、Cloud Connectorのセカンダリブローカーに情報を同期(コピー)します(セカンダリブローカーは、上記の図で示されているようにHigh Availability ServiceまたはHAブローカーとも呼ばれます)。
前回のチェック以降に変更された項目だけでなく、すべての構成データがコピーされます。CSSは、Cloud Connector上のMicrosoft SQL Server Express LocalDBデータベースに構成データをインポートします。このデータベースはローカルホストキャッシュデータベースとして参照されます。CSSは、ローカルホストキャッシュデータベースの情報がCitrix Cloudのサイトデータベースの情報と一致することを確認します。ローカルホストキャッシュデータベースは、同期が発生するたびに再作成されます。
Cloud Connectorをインストールする場合、(ローカルホストキャッシュデータベースで使用するために)自動でMicrosoft SQL Server Express LocalDBがインストールされますローカルホストキャッシュデータベースをCloud Connector間で共有することはできません。ローカルホストキャッシュデータベースのバックアップを作成する必要はありません。構成の変更が検出されるたびに再作成されます。
- 前回のチェック以降に変更が発生行われていない場合、構成データはコピーされません。
停止状態中
停止状態が開始された場合:
- セカンダリブローカーは、接続要求のリッスンと処理を開始します。
- 停止状態の開始時には、セカンダリブローカーに最新のVDA登録データはありませんが、VDAとの通信が始まると登録処理がトリガーされます。その処理中、セカンダリブローカーは、そのVDAに関する現在のセッション情報も取得します。
- セカンダリブローカーが接続を処理する間も、プリンシパルブローカーは引き続きCitrix Cloudへの接続を監視します。接続が回復すると、プリンシパルブローカーはセカンダリブローカーに接続情報のリスニングを停止するように指示して、仲介操作を再開します。VDAがプリンシパルブローカーと次に通信するときに、登録処理がトリガーされます。セカンダリブローカーは、前回の停止状態以降に残っているVDA登録をすべて削除します。CSSは、Citrix Cloudで構成が変更されたことを検出すると、情報の同期を再開します。
同期中に停止状態が開始されるという可能性の低い事象では、その時点のインポートは破棄され、最新の既知の構成が使用されます。
イベントログに、同期および停止状態が発生した時刻が記録されます。
停止モードでの操作に時間制限は適用されませんが、
意図的に停止を引き起こすこともできます。これを行う理由と方法について詳しくは、「停止状態の強制」を参照してください。
リソースの場所にCloud Connectorが複数存在する場合
CSSは、他のタスクの合間に、リソースの場所内にあるすべてのCloud Connectorに関する情報を定期的にセカンダリブローカーに提供しますリソースの場所で他のCloud Connectorを実行している各セカンダリブローカーは、この情報からすべてのピアセカンダリブローカーを把握します。
セカンダリブローカーは独立したチャネルで相互に通信します。これらのセカンダリブローカーは、実行しているマシンのFQDN名のアルファベット順の一覧を使用して、停止状態が発生したときにどのセカンダリブローカーがゾーン内の仲介操作を担当するかを決定(選出)します。停止状態中、すべてのVDAが、選出されたセカンダリブローカーに再登録します。選出されていないゾーン内のセカンダリブローカーは、受信接続とVDA登録要求を能動的に拒否します。
停止状態中に、選出されたセカンダリブローカーに障害が発生した場合、別のセカンダリブローカーが選出されて処理を引き継ぎ、VDAは新しく選出されたセカンダリブローカーに登録されます。
停止状態中にCloud Connectorを再起動した場合:
- このCloud Connectorがブローカーに選出されていない場合は、再起動しても影響はありません。
- このCloud Connectorをブローカーに選出している場合は、別Cloud Connectorが選出されてVDAはそちらに登録されます。再起動したCloud Connectorの電源がオンになると、このCloud Connectorが自動的に仲介処理を引き継ぐため、VDAはこちらのConnectorにもう一度登録されます。このシナリオでは、登録中にパフォーマンスに影響が生じることがあります。
イベントログには、選出に関する情報が含まれます。
停止状態中にできなくなること、およびその他の相違点
停止モードでの操作に時間制限は適用されませんが、リソースの場所からCitrix Cloudの接続が失われた場合は、可能な限り迅速にリソースの場所の接続を復元することをお勧めします。
停止状態中:
- [管理] インターフェイスは使用できません。
-
Remote PowerShell SDKへのアクセスが制限されます。
- 次のことを最初に行う必要があります:
- レジストリキー
EnableCssTestMode
を値1で追加します:New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
- SDKプロキシがコマンドレット呼び出しをリダイレクトしようとしないようにするため、SDK認証を
OnPrem
に設定します:$XDSDKAuth="OnPrem"
- ポート89を使用します:
Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ContollerDNSName, DesktopGroupName, RegistrationState
- レジストリキー
- これらのコマンドを実行すると、次のものを使用できるようになります:
- すべての
Get-Broker*
コマンドレット。 - 電源管理コマンドレット
New-BrokerHostingPowerAction
、Set-BrokerHostingPowerAction
、およびRemove-BrokerHostingPowerAction
。
- すべての
- 次のことを最初に行う必要があります:
- 停止状態中は、監視データがCitrix Cloudに送信されなくなります。このため、[監視]機能には、停止状態中のアクティビティは表示されません。
-
ハイパーバイザー資格情報をホストサービスから取得できません。すべてのマシンの電力状態が不明で、電源操作を発行できません。ただし、電源が入っているホスト上のVMを接続要求のために使用することができます。
- 割り当てられたマシンは、通常の操作中に割り当てが発生した場合のみ使用できます。停止状態中は新しい割り当てはできません。
- リモートPCアクセスマシンの自動登録と構成はできません。ただし、通常の操作中に登録、構成されたマシンは使用できます。
- サーバーでホストされるアプリケーションとデスクトップのユーザーは、リソースが異なるゾーンにある場合、構成されている最大セッション数よりも多くのセッションを使用できる場合があります。
- ユーザーは、現在アクティブ/選択されているブローカーを含むゾーン内の登録済みVDAからのみ、アプリケーションとデスクトップを起動できます。停止状態中は、ゾーン間での起動(あるゾーンのブローカーから別のゾーンのVDAへ)はサポートされません。
- デリバリーグループ内のVDAに対してスケジュールされた再起動が開始される前にサイトデータベースの停止が発生した場合、停止が終了すると再起動が開始されます。このシナリオは意図しない結果につながる可能性があります。詳しくは、「データベースの停止によるスケジュールされた再起動の遅延」を参照してください。
- [ゾーン優先度]を構成できません。構成されていても、環境設定はセッション起動では考慮されません。
- タグを使用してリソースの場所を指定するタグ制限機能は、セッション起動ではサポートされていません。このタグ制限が構成されていて、StoreFrontストアの [詳細なヘルスチェック] オプションが有効になっている場合、セッションが断続的に起動に失敗することがあります。
StoreFrontの要件
ローカルホストキャッシュを使用するには、展開の一部として、顧客が展開したオンプレミスのStoreFrontが必要です。VDAが登録されている(または登録できる)すべてのCloud Connectorを、Delivery ControllerとしてStoreFrontに追加する必要があります。StoreFrontに追加されていないCloud Connectorは停止モードに移行できないため、ユーザーの起動に失敗することがあります。
リソースの可用性
停止状態中のリソースの可用性(アプリとデスクトップ)を確保するには、次の2 つの方法があります:
- 展開内のすべてのリソースの場所にリソースを公開します。
-
リソースを少なくとも1つのリソースの場所に公開します。次に、以下の手順に従って、各StoreFrontストアで詳細なヘルスチェック機能を有効にします。
- 各リソースの場所のStoreFrontインストールをバージョン1912 CU4以降にアップグレードします。詳しくは、StoreFrontのドキュメントを参照してください。
-
StoreFrontストアごとに、詳細なヘルスチェックオプションを有効にします。ストアの
web.config
ファイルのfarmsets
の下にadvancedHealthCheck="on"
を追加します。オプションの例:
- ファイルの更新後、手動でIISを再起動します。web.configファイルの更新を繰り返し、他のストア用にIISを再起動します。
アプリケーションとデスクトップのサポート
ローカルホストキャッシュは、顧客が展開するStoreFrontでのみ機能します。Citrix Workspaceでの使用はサポートされていません。
ローカルホストキャッシュは、サーバーでホストされるアプリケーションおよびデスクトップ、および静的な(割り当て済み)デスクトップをサポートします。
ローカルホストキャッシュは、以下のようにプールされたデリバリーグループでデスクトップ(シングルセッション)VDAをサポートします。
-
デフォルトでは、停止状態が発生した場合、「
ShutdownDesktopsAfterUse
」プロパティが有効なプールされたデリバリーグループ内で電源管理されているデスクトップVDA(MCSまたはCitrix Provisioningによって作成)は、メンテナンスモードになります。このデフォルトの設定を変更して、停止状態中にこれらのデスクトップを使用できるようにすることができます。ただし、停止状態中は電源管理が機能しないことがあります(通常の操作を開始すると電源管理が始まります)。また、これらのデスクトップは再起動していないため、前のユーザーのデータが含まれている可能性があります。
-
デフォルトの動作を上書きするには、PowerShellコマンドを使用して、影響を受けるデリバリーグループごとにサイト全体でこの機能を有効にする必要があります。
サイト全体の場合は、次のコマンドを実行します:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
デフォルトでは、すべてのデリバリーグループでこの機能が有効になっているわけではありません。デリバリーグループレベルで有効にするには、次の2つのオプションがあります:
-
選択したデリバリーグループに対して有効にする: 影響を受けるデリバリーグループごとに、次のコマンドを実行します。
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
-
すべてのデリバリーグループに対して有効にする: デフォルトでデリバリーグループレベルの設定を有効にするには、次のコマンドを実行します。この設定は、新しく作成されたすべてのデリバリーグループ(つまり、設定を有効にした後に作成したすべてのデリバリーグループ)に適用されます。
Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true
既存のデリバリーグループに対してこれを有効にするには、前述のコマンド(
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
)を実行します。
この機能をサイトでデリバリーグループごとに有効にしても、構成済みの
ShutdownDesktopsAfterUse
プロパティの、通常操作時の動作には影響がありません。 -
重要:
サイトレベルでReuseMachinesWithoutShutdownInOutageAllowedを有効にし、デリバリーグループレベルでReuseMachinesWithoutShutdownInOutageを有効にしないと、プールされたデリバリーグループ内の電源管理されたデスクトップVDAに対するすべてのセッション起動の試みが、ローカルホストキャッシュイベント中に失敗します。
XenApp 6.xリリースとの相違点
このローカルホストキャッシュ実装は、XenApp 6.x以前のXenAppリリースのローカルホストキャッシュ機能の名前を共有しますが、これは技術的に完全に異なる実装です。これは大幅に改善された実装で、破損に対してより頑強で耐性があり、メンテナンスも少なくて済みます。
ローカルホストキャッシュの管理
Citrix DaaS環境では、ローカルホストキャッシュは常に有効になっています。構成や管理の操作を行う必要はありません。
前述のように、Cloud Connectorをリソースの場所にインストールするとMicrosoft SQL Server Express LocalDBデータベースが自動でインストールされます。このデータベースを無効にしたり、削除したりしないでくださいCloud ConnectorはCitrixにより定期的に更新されます。SQL Server Express LocalDBソフトウェアを手動で無効にするか削除しても、次回のCloud Connectorの更新時に置き換えられます。
ローカルホストキャッシュが動作していることを確認する
ローカルホストキャッシュが正しく構成されていることを確認する方法を以下の動画で説明します。
ローカルホストキャッシュが適切に設定され動作していることを確認するには:
- リソースの場所に、このリソースの場所内のすべてのCloud ConnectorをポイントするローカルのStoreFrontが含まれていることを確認します。
- 同期のインポートが正常に完了していることを確認します。イベントログをチェックします。
- 各Cloud Connectorにローカルホストキャッシュデータベースが作成されていることを確認します。これにより、必要に応じてHigh Availability Serviceが処理を引き継げるようになります。
- Cloud Connectorサーバーで
c:\Windows\ServiceProfiles\NetworkService
を参照します。 -
HaDatabaseName.mdf
およびHaDatabaseName_log.ldf
が作成されたことを確認します。
- Cloud Connectorサーバーで
- リソースの場所にあるすべてのCloud Connectorを強制的に停止します。ローカルホストキャッシュが動作することを確認したら、すべてのCloud Connectorを通常モードに戻します。これには約15分かかります。
イベントログ
イベントログに、同期および停止状態が発生した時刻が示されます。イベントビューアーのログでは、停止状態モードはHAモードと見なされます。
Config Synchronizer Service
通常の操作中、ローカルホストキャッシュブローカーを使用してCSSが構成データをローカルホストキャッシュデータベースにインポートすると次のイベントが発生することがあります。
- 503:Citrix Config Sync Serviceが更新された構成を受信しました。このイベントは、Citrix Cloudから更新済みの構成を受信するたびに発生します。このイベントは、同期プロセスが開始されたことを表します。
- 504:Citrix Config Sync Serviceが更新された構成をインポートしました。構成のインポートが正常に完了しました。
- 505:Citrix Config Sync Serviceがインポートに失敗しました。構成のインポートが正常に完了しませんでした。過去に正常にインポートされた構成がある場合、停止状態の発生時にはその構成が使用されます。ただし、この構成は現在の構成よりも古いものです。使用可能な過去の構成がない場合、停止状態中、サービスはセッション仲介に参加できません。この場合は、「トラブルシューティング」セクションを確認の上、Citrixサポートにお問い合わせください。
- 507:システムが停止状態であり、ローカルホストキャッシュブローカーが使用中であるため、Citrix Config Sync Serviceによりインポートが中止されました。サービスは新しい構成を受け取りましたが、停止状態が発生したためインポートは中止されました。これは正常な動作です。
- 510:プライマリ構成サービスから構成サービス構成データを受信していません。
- 517:プライマリブローカーとの通信に問題がありました。
- 518:セカンダリブローカー(High Availability Service)が実行されていないため、Config Syncスクリプトが中止されました。
高可用性サービス
このサービスは、ローカルホストキャッシュブローカーとも呼ばれます。
- 3502:停止状態が発生しローカルホストキャッシュブローカーが仲介操作を実行しています。
- 3503:停止状態が解消され、通常の操作が再開しました。
- 3504:どのローカルホストキャッシュブローカーが選出されたかと、選出に関わった他のローカルホストキャッシュブローカーを示します。
停止状態の強制
停止状態は意図的に発生させることもできます。
- ネットワークが稼動と停止を繰り返している場合。ネットワークの問題が解決するまで強制的に停止状態にすることにより、通常モードと停止状態モードの移行が繰り返され、VDA登録ストームが頻繁に発生するのを防げます。
- 障害回復プランをテストするには:
- ローカルホストキャッシュが正常に動作することを確認する場合。
Cloud Connectorは強制停止中に更新できますが、予期しない問題が発生する可能性があります。強制停止モードの間隔を避けるために、Cloud Connectorの更新のスケジュールを設定することをお勧めします。
強制的に停止状態にするには、各Cloud Connectorサーバーのレジストリを編集します。HKLM\Software\Citrix\DesktopServer\LHC
でOutageModeForced
を作成し、REG_DWORD
を1
に設定します。この設定により、ローカルホストキャッシュブローカーはCitrix Cloudへの接続状態に関係なく停止状態モードに入ります。値を0
に設定すると、ローカルホストキャッシュブローカーの停止状態モードは終了します。
イベントを確認するには、C:\ProgramData\Citrix\workspaceCloud\Logs\Plugins\HighAvailabilityService
のCurrent_HighAvailabilityService
ログファイルを監視します。
トラブルシューティング
ローカルホストキャッシュデータベースへの同期インポートが失敗し505イベントがポストされた場合には、次のトラブルシューティングツールが役立ちます。
CDFトレーシング: ConfigSyncServerモジュールおよびBrokerLHCモジュール向けのオプションが用意されています。これらのオプションと他のブローカーモジュールを組み合わせることで、問題を特定できます。
レポート: 同期インポートが失敗した場合、レポートを生成できます。このレポートの最後に、エラーの原因となったオブジェクトが記載されています。このレポート機能は同期速度に影響するため、Citrixでは使用しないときは無効にしておくことをお勧めします。
CSSトレースレポートを有効化および作成するには、次のコマンドを入力します:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC
-Name EnableCssTraceMode -PropertyType DWORD -Value 1
HTMLレポートはC:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html
に格納されます。
レポートが生成されたら、次のコマンドを入力してレポート機能を無効にします:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC
-Name EnableCssTraceMode -Value 0
追加情報
以下については、「ローカルホストキャッシュのスケールおよびサイズの考慮事項」を参照してください:
- テスト方法と結果
- RAMサイズの考慮事項
- CPUコアとソケットの構成に関する考慮事項
- ストレージの考慮事項