ローカルホストキャッシュ
XenAppおよびXenDesktopサイトデータベースが常に利用可能であることを保証するため、Citrixは、Microsoftの可用性に関するベストプラクティスに従い、フォールトトレラントなSQL Server展開から始めることを推奨します。（(/ja-jp/xenapp-and-xendesktop/7-15-ltsr/system-requirements.html)記事の「データベース」セクションには、XenAppおよびXenDesktopでサポートされているSQL Serverの高可用性機能が記載されています。）しかし、ネットワークの問題や中断により、ユーザーがアプリケーションやデスクトップに接続できなくなる場合があります。
Local Host Cache (LHC) 機能により、障害発生時でもXenAppまたはXenDesktopサイトでの接続仲介操作を続行できます。障害は、Delivery Controller™とサイトデータベース間の接続が失敗したときに発生します。サイトデータベースに90秒間アクセスできない場合、Local Host Cacheが作動します。
Local Host Cacheは、XenAppおよびXenDesktopで最も包括的な高可用性機能です。これは、XenApp 7.6で導入された接続リース機能よりも強力な代替手段です。
このLocal Host Cacheの実装は、XenApp 6.xおよびそれ以前のXenAppリリースにおけるLocal Host Cache機能と同じ名前を共有していますが、大幅な改善が加えられています。この実装はより堅牢で、破損の影響を受けません。定期的なdsmaintコマンドの必要性を排除するなど、メンテナンス要件が最小限に抑えられています。このLocal Host Cacheは技術的には全く異なる実装です。その仕組みについては、引き続きお読みください。
注：
バージョン7.15 LTSRでは接続リースがサポートされていますが、次のリリースでは削除されます。
データコンテンツ
Local Host Cacheには以下の情報が含まれています。これはメインデータベースの情報の一部です。
- サイトから公開されたリソースへの権限が具体的に割り当てられているユーザーとグループのID。
- サイトから公開されたリソースを現在使用している、または最近使用したユーザーのID。
- サイトで構成されているVDAマシン（Remote PC Accessマシンを含む）のID。
- 公開されたリソースへの接続に積極的に使用されているクライアントCitrix Receiver™マシンのID（名前とIPアドレス）。
また、メインデータベースが利用できなかった間に確立された、現在アクティブな接続に関する情報も含まれています。
- Citrix Receiverによって実行されたクライアントマシンのエンドポイント分析の結果。
- サイトに関わるインフラストラクチャマシン（NetScaler GatewayやStoreFront™サーバーなど）のID。
- ユーザーによる最近のアクティビティの日時と種類。
動作の仕組み
次の図は、通常の操作におけるローカルホストキャッシュのコンポーネントと通信パスを示しています。
通常の操作中:
- Controller上のプライマリブローカー（Citrix Broker Service）は、StoreFrontからの接続要求を受け入れ、サイトデータベースと通信して、Controllerに登録されているVDAにユーザーを接続します。
- プライマリブローカーの構成に変更が加えられたかどうかを判断するために、2分ごとにチェックが行われます。これらの変更は、PowerShell/Studioアクション（デリバリーグループのプロパティの変更など）またはシステムアクション（マシン割り当てなど）によって開始された可能性があります。
- 前回のチェック以降に変更があった場合、プライマリブローカーはCitrix Config Synchronizer Service (CSS) を使用して、Controller上のセカンダリブローカー（Citrix High Availability Service）に情報を同期（コピー）します。前回のチェック以降に変更された項目だけでなく、すべてのブローカー構成データがコピーされます。セカンダリブローカーは、データをController上のMicrosoft SQL Server Express LocalDBデータベースにインポートします。CSSは、セカンダリブローカーのLocalDBデータベースの情報がサイトデータベースの情報と一致することを保証します。LocalDBデータベースは、同期が行われるたびに再作成されます。
- 前回のチェック以降に変更がない場合、データはコピーされません。
次の図は、プライマリブローカーがサイトデータベースとの接続を失った場合（障害が発生した場合）の通信パスの変化を示しています。
障害発生時:
- プライマリブローカーはサイトデータベースと通信できなくなり、StoreFrontおよびVDA情報のリスニングを停止します（図中のXで示されています）。その後、プライマリブローカーはセカンダリブローカー（High Availability Service）に、接続要求のリスニングと処理を開始するよう指示します（図中の赤い破線で示されています）。
- 障害が発生すると、セカンダリブローカーには現在のVDA登録データがありませんが、VDAがセカンダリブローカーと通信するとすぐに、再登録プロセスがトリガーされます。そのプロセス中に、セカンダリブローカーは当該VDAに関する現在のセッション情報も取得します。
- セカンダリブローカーが接続を処理している間、プライマリブローカーは引き続きサイトデータベースへの接続を監視します。接続が復元されると、プライマリブローカーはセカンダリブローカーに接続情報のリスニングを停止するよう指示し、プライマリブローカーはブローカー操作を再開します。次にVDAがプライマリブローカーと通信するときに、再登録プロセスがトリガーされます。セカンダリブローカーは、以前の停止からの残りのVDA登録をすべて削除し、CSSから受信した構成変更でLocalDBデータベースの更新を再開します。
同期中に停止が発生するという万が一の事態では、現在のインポートは破棄され、最後に認識された構成が使用されます。
イベントログには、同期と停止に関する情報が提供されます。詳細については、以下の「監視」セクションを参照してください。
意図的に停止をトリガーすることもできます。その理由と方法の詳細については、以下の「停止を強制する」セクションを参照してください。
複数のControllerがあるサイト
CSSは、他のタスクの中でも、ゾーン内のすべてのControllerに関する情報をセカンダリブローカーに定期的に提供します。（展開に複数のゾーンが含まれていない場合、このアクションはサイト内のすべてのControllerに影響します。）この情報を持つことで、各セカンダリブローカーはすべてのピアセカンダリブローカーについて認識しています。
セカンダリブローカーは、別のチャネルで互いに通信します。停止が発生した場合にゾーンでブローカー操作を担当するセカンダリブローカーを決定（選出）するために、実行中のマシンのFQDN名のアルファベット順リストを使用します。停止中、すべてのVDAは選出されたセカンダリブローカーに再登録します。ゾーン内の選出されていないセカンダリブローカーは、受信接続およびVDA登録要求を積極的に拒否します。
停止中に選出されたセカンダリブローカーが失敗した場合、別のセカンダリブローカーが選出されて引き継ぎ、VDAは新しく選出されたセカンダリブローカーに再登録します。
停止中にControllerが再起動された場合：
- そのControllerが選出されたプライマリブローカーでない場合、再起動による影響はありません。
- そのControllerが選出されたプライマリブローカーである場合、別のControllerが選出され、VDAが再登録されます。再起動されたControllerが起動すると、自動的にブローカー処理を引き継ぎ、VDAが再度再登録されます。このシナリオでは、再登録中にパフォーマンスが影響を受ける可能性があります。
通常の操作中にControllerの電源を切り、停止中に電源を入れた場合、そのControllerがプライマリブローカーとして選出されていると、そのControllerでローカルホストキャッシュを使用できません。
イベントログには、選出に関する情報が提供されます。以下の「監視」セクションを参照してください。
設計上の考慮事項と要件
ローカルホストキャッシュは、サーバーでホストされるアプリケーションとデスクトップ、および静的（割り当て済み）デスクトップでサポートされています。プールされたVDIデスクトップ（MCSまたはPVSによって作成されたもの）ではサポートされていません。
障害モードでの運用に時間制限はありません。ただし、できるだけ早くサイトを通常の運用状態に戻してください。
障害中に利用できないもの、または変更されるもの:
- Studioを使用したり、PowerShellコマンドレットを実行したりすることはできません。
- ホストサービスからハイパーバイザーの資格情報を取得することはできません。すべてのマシンは不明な電源状態になり、電源操作を発行することはできません。ただし、電源がオンになっているホスト上のVMは、接続要求に使用できます。
- 割り当てられたマシンは、通常の運用中に割り当てが行われた場合にのみ使用できます。障害中に新しい割り当てを行うことはできません。
- Remote PC Accessマシンの自動登録と構成はできません。ただし、通常の運用中に登録および構成されたマシンは使用可能です。
- リソースが異なるゾーンにある場合、サーバーでホストされているアプリケーションおよびデスクトップのユーザーは、構成されたセッション制限よりも多くのセッションを使用する可能性があります。
- ユーザーは、現在アクティブ/選出されている（セカンダリ）ブローカーを含むゾーン内の登録済みVDAからのみアプリケーションとデスクトップを起動できます。ゾーンをまたぐ起動（あるゾーンのブローカーから別のゾーンのVDAへの起動）は、障害中はサポートされません。
デフォルトでは、ShutdownDesktopsAfterUseプロパティが有効になっているプールされたデリバリーグループの電源管理デスクトップVDAは、障害発生時にメンテナンスモードになります。このデフォルトを変更して、障害中にこれらのデスクトップを使用できるようにすることができます。ただし、障害中の電源管理に頼ることはできません。（電源管理は通常の運用が再開された後に再開されます。）また、これらのデスクトップは再起動されていないため、以前のユーザーのデータが含まれている可能性があります。
デフォルトの動作を上書きするには、サイト全体で、および影響を受ける各デリバリーグループに対して有効にする必要があります。
サイトの場合、次のPowerShellコマンドレットを実行します。
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
影響を受ける各デリバリーグループの場合、次のPowerShellコマンドレットを実行します。
Set-BrokerDesktopGroup -Name "\<*name*\>" -ReuseMachinesWithoutShutdownInOutage $true
サイトおよびデリバリーグループでこの機能を有効にしても、構成されたShutdownDesktopsAfterUseプロパティが通常の運用中にどのように機能するかには影響しません。
RAMサイズ：
LocalDBサービスは約1.2 GBのRAM（データベースキャッシュに最大1 GB、SQL Server Express LocalDBの実行に200 MB）を使用できます。高可用性サービスは、多数のログオンが発生する長時間の停止（例：10,000ユーザーで12時間）が続く場合、最大1 GBのRAMを使用できます。これらのメモリ要件は、Controllerの通常のRAM要件に追加されるものです。そのため、RAM容量の合計を増やす必要がある場合があります。
なお、SiteデータベースにSQL Server Expressインストールを使用する場合、サーバーには2つのsqlserver.exeプロセスが存在します。
CPUコアとソケットの構成：
ControllerのCPU構成、特にSQL Server Express LocalDBに利用可能なコア数は、メモリ割り当てよりもさらにローカルホストキャッシュのパフォーマンスに直接影響します。このCPUオーバーヘッドは、データベースにアクセスできず、高可用性サービスがアクティブな停止期間中にのみ発生します。
LocalDBは複数のコア（最大4つ）を使用できますが、単一のソケットに制限されます。ソケットを追加してもパフォーマンスは向上しません（例：1コアずつ4ソケットの場合）。代わりに、Citrixは複数のソケットと複数のコアを使用することを推奨しています。Citrixのテストでは、2x3（2ソケット、3コア）構成が4x1および6x1構成よりも優れたパフォーマンスを示しました。
ストレージ：
停止中にユーザーがリソースにアクセスすると、LocalDBは増大します。例えば、1秒あたり10ログオンで実行されるログオン/ログオフテスト中に、データベースは2～3分ごとに1MB増加しました。通常の操作が再開されると、ローカルデータベースは再作成され、スペースは解放されます。ただし、ブローカーは、停止中のデータベースの増大に対応できるよう、LocalDBがインストールされているドライブに十分な空き容量が必要です。ローカルホストキャッシュは、停止中に追加のI/Oも発生させます：1秒あたり約3MBの書き込みと、数十万回の読み取りが発生します。
パフォーマンス：
停止中は1つのブローカーがすべての接続を処理するため、通常の操作中に複数のController間で負荷分散を行うSite（またはゾーン）では、停止中に選出されたブローカーが通常よりもはるかに多くの要求を処理する必要がある場合があります。そのため、CPUの要求は高くなります。Site（ゾーン）内のすべてのブローカーは、LocalDBと影響を受けるすべてのVDAによって課される追加の負荷を処理できる必要があります。停止中に選出されるブローカーは変更される可能性があるためです。
VDIの制限：
- シングルゾーンVDI展開では、停止中に最大10,000台のVDAを効率的に処理できます。
- マルチゾーンVDI展開では、停止中に各ゾーンで最大10,000台のVDAを効率的に処理でき、Site全体で最大40,000台のVDAまで対応可能です。例えば、以下の各Siteは停止中に効率的に処理できます。
- 4つのゾーンを持つSiteで、各ゾーンに10,000台のVDAが含まれる場合。
- 7つのゾーンを持つSiteで、1つのゾーンに10,000台のVDAが含まれ、残りの6つのゾーンにそれぞれ5,000台のVDAが含まれる場合。
障害発生中、サイト内の負荷管理が影響を受ける可能性があります。負荷評価機能（特にセッション数ルール）が超過する場合があります。
すべてのVDAがブローカーに再登録するまでの間、そのブローカーは現在のセッションに関する完全な情報を持っていない可能性があります。そのため、その期間中のユーザー接続要求により、既存のセッションへの再接続が可能であったとしても、新しいセッションが起動される可能性があります。この期間（「新しい」ブローカーが再登録中にすべてのVDAからセッション情報を取得する間）は避けられません。障害発生時に接続されていたセッションは移行期間中に影響を受けませんが、新しいセッションやセッションの再接続は影響を受ける可能性があります。
この期間は、VDAが別のブローカーに再登録する必要がある場合に発生します。
- 障害の開始：プリンシパルブローカーからセカンダリブローカーへの移行時。
- 障害発生時のブローカー障害：障害が発生したセカンダリブローカーから新しく選出されたセカンダリブローカーへの移行時。
- 障害からの復旧：通常の操作が再開され、プリンシパルブローカーが制御を再開する時。
Citrix Broker ProtocolのHeartbeatPeriodMsレジストリ値（デフォルト = 600000 ms、つまり10分）を低くすることで、間隔を短縮できます。このハートビート値は、VDAがpingに使用する間隔の2倍であるため、デフォルト値では5分ごとにpingが実行されます。
たとえば、次のコマンドはハートビートを5分（300000ミリ秒）に変更し、2.5分ごとにpingが実行されるようにします。
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
VDAがどれだけ速く登録されても、この間隔を完全に排除することはできません。
ブローカー間で同期にかかる時間は、オブジェクト（VDA、アプリケーション、グループなど）の数に応じて増加します。たとえば、5000台のVDAを同期するには、10分以上かかる場合があります。イベントログの同期エントリについては、以下の「監視」セクションを参照してください。
ローカルホストキャッシュの管理
ローカルホストキャッシュが正常に機能するには、各コントローラーのPowerShell実行ポリシーがRemoteSigned、Unrestricted、またはBypassに設定されている必要があります。
SQLサーバー エクスプレス ローカルDB
ローカルホストキャッシュが使用するMicrosoft SQL Server Express LocalDBは、コントローラーをインストールするか、7.9より前のバージョンからコントローラーをアップグレードすると自動的にインストールされます。LocalDBの管理者によるメンテナンスは不要です。セカンダリブローカーのみがこのデータベースと通信します。PowerShellコマンドレットを使用してこのデータベースに関する何も変更することはできません。LocalDBはコントローラー間で共有できません。
ローカルホストキャッシュが有効になっているかどうかにかかわらず、SQL Server Express LocalDBデータベースソフトウェアがインストールされます。
そのインストールを防ぐには、XenDesktopServerSetup.exeコマンドを使用してControllerをインストールまたはアップグレードし、/exclude “Local Host Cache Storage (LocalDB)”オプションを含めます。ただし、データベースがないとローカルホストキャッシュ機能は動作せず、セカンダリブローカーで別のデータベースを使用することはできないことに注意してください。
このLocalDBデータベースのインストールは、サイトデータベースとして使用するためにSQL Server Expressをインストールするかどうかには影響しません。
XenAppまたはXenDesktop®のインストールおよびアップグレード後のデフォルト設定
XenApp®およびXenDesktopの新規インストール中、ローカルホストキャッシュはデフォルトで有効になっています。（接続リースはデフォルトで無効になっています。）
アップグレード後も、ローカルホストキャッシュの設定は変更されません。たとえば、以前のバージョンでローカルホストキャッシュが有効になっていた場合、アップグレードされたバージョンでも有効のままです。以前のバージョンでローカルホストキャッシュが無効になっていた（またはサポートされていなかった）場合、アップグレードされたバージョンでも無効のままです。
ローカルホストキャッシュの有効化と無効化
ローカルホストキャッシュを有効にするには、次を入力します。
Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false
このコマンドレットは、接続リース機能も無効にします。ローカルホストキャッシュと接続リースの両方を有効にしないでください。
ローカルホストキャッシュが有効になっているかどうかを確認するには、次を入力します。
Get-BrokerSite
LocalHostCacheEnabled プロパティが True になっていること、および ConnectionLeasingEnabled プロパティが False になっていることを確認してください。
ローカルホストキャッシュを無効にする（および接続リースを有効にする）には、次を入力します。
Set-BrokerSite -LocalHostCacheEnabled $false -ConnectionLeasingEnabled $true
Local Host Cacheが機能していることを確認する
Local Host Cacheが正しくセットアップされ、機能していることを確認するには、次の手順を実行します。
- 同期インポートが正常に完了していることを確認します。イベントログを確認してください。
- 各Delivery ControllerにSQL Server Express LocalDBデータベースが作成されていることを確認します。これにより、必要に応じて高可用性サービスが引き継ぐことができることが確認されます。
- デリバリーコントローラーサーバーで、C:\Windows\ServiceProfiles\NetworkService というフォルダーにアクセスします。
- データベースファイルであるHaDatabaseName.mdfとHaDatabaseName_log.ldfが正しく作成されていることを確認します。
- Delivery Controllerで障害を強制的に発生させます。Local Host Cacheが機能することを確認したら、すべてのControllerを通常モードに戻すことを忘れないでください。VDA登録ストームを回避するため、これには約15分かかる場合があります。
障害を強制的に発生させる
意図的にデータベースの障害を強制的に発生させたい場合があります。
- ネットワークが繰り返し停止したり起動したりする場合。ネットワークの問題が解決するまで障害を強制的に発生させることで、通常モードと障害モード間の継続的な移行を防ぎます。
- ディザスタリカバリ計画をテストするため。
- サイトデータベースサーバーの交換または保守中。
障害を強制的に発生させるには、Delivery Controllerを含む各サーバーのレジストリを編集します。
- HKLM\Software\Citrix\DesktopServer\LHCで、OutageModeForcedを1に設定します。これにより、データベースの状態に関係なく、ブローカーは障害モードに入るように指示されます。（値を0に設定すると、サーバーは障害モードから解除されます。）
- Citrix Cloud™シナリオでは、コントロールプレーンまたはプライマリゾーンへの接続状態に関係なく、コネクタは障害モードに入ります。
監視
イベントログは、同期と停止が発生した時期を示します。
構成同期サービス:
通常の操作中に、CSSがブローカー構成をコピーおよびエクスポートし、高可用性サービス（セカンダリブローカー）を使用してLocalDBにインポートすると、次のイベントが発生する可能性があります。
- 503: プリンシパルブローカー構成に変更が見つかり、インポートが開始されています。
- 504: ブローカー構成がコピー、エクスポートされ、LocalDBに正常にインポートされました。
- 505: LocalDBへのインポートに失敗しました。詳細については以下を参照してください。
- 510: プライマリ構成サービスから構成サービス構成データが受信されませんでした。
- 517: プライマリブローカーとの通信に問題が発生しました。
- 518: セカンダリブローカー（高可用性サービス）が実行されていないため、Config Syncスクリプトが中止されました。
高可用性サービス:
- 3502: 停止が発生し、セカンダリブローカー（高可用性サービス）がブローカー操作を実行しています。
- 3503: 停止が解決され、通常の操作が再開されました。
- 3504: どのセカンダリブローカーが選出されたか、および選出に関与した他のブローカーを示します。
トラブルシューティング
LocalDBへの同期インポートが失敗し、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
ブローカー構成のエクスポート: デバッグ目的で正確な構成を提供します。
Export-BrokerConfiguration | Out-File file-pathname
例えば、Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml。